Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-40951

System triggers give no visibility into slow/failed execution and misreport server readiness

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • N/A
    • 13.2
    • Triggers
    • None
    • Q4/2026 Server Maintenance

    Description

      CREATE TABLE t (a INT);
       
      --delimiter //
      CREATE TRIGGER slowstart1 AFTER STARTUP
      BEGIN
        DECLARE i INT DEFAULT 0;
        WHILE i < 20 DO
          DO SLEEP(5);
          SET i = i + 1;
        END WHILE;
        INSERT INTO test.t VALUES (1);
      END//
      --delimiter ;
       
      --source include/restart_mysqld.inc
       
      select * from t;
      

      --source include/have_innodb.inc
      SET GLOBAL innodb_lock_wait_timeout = 10;
      CREATE TABLE t (a INT) ENGINE=InnoDB;
      INSERT INTO t VALUES (1);
      CREATE TRIGGER tr1 BEFORE SHUTDOWN UPDATE test.t SET a=2 WHERE a=1;
       
      --connect (a, localhost, root,,test)
      BEGIN;
      SELECT * FROM t WHERE a=1 FOR UPDATE;
       
      --connection default
      --source include/restart_mysqld.inc
       
      SELECT * FROM t;
      DROP TRIGGER tr1;
      DROP TABLE t;
      

      1) No observability

      While a slow STARTUP or SHUTDOWN trigger is executing, the server gives no indication anything is happening. Nothing is written to the error log — no "running startup trigger X". From the outside, the server just appears hung: the process is up, but there's no way to tell it's mid-trigger versus stuck versus broken. This gets worse combined with silent-failure behavior: if the trigger body errors out partway through, that's also not logged — a failed trigger and a slow-but-fine trigger look identical from the log. (check test 2 - there update waits innodb_lock_wait_timeout and ends up with an error)

      2) "ready for connections" is logged before the server can actually accept connections

      ready for connections is written to the error log before AFTER STARTUP triggers run, not after. Startup triggers execute after that line is printed and before the accept loop starts, so the log claims readiness while the server is still blocked running trigger bodies.

      3) SLEEP() inside a system trigger doesn't sleep for the requested duration

      SLEEP(10) called inside a system trigger body does not block for 10 seconds. It's silently capped at ~5 seconds regardless of the argument — confirmed with values from 3 up to 1000: anything above ~5s returns after one fixed ~5-second poll interval, not after the requested time. If user uses SLEEP() for a delay intentionally - it will not work.

      CREATE TRIGGER tr1 AFTER STARTUP select sleep(100) into @x;
      --source include/restart_mysqld.inc
       
      SELECT 1;
      

      Attachments

        Issue Links

          Activity

            People

              shulga Dmitry Shulga
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 8.05d
                  8.05d
                  Remaining:
                  Remaining Estimate - 8.05d
                  8.05d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                  Git Integration

                    Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.