Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
N/A
-
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
- is caused by
-
MDEV-30645 CREATE TRIGGER FOR { STARTUP | SHUTDOWN }
-
- Stalled
-