Vladislav Vaintroub added a comment - 2021-10-04 09:03 - edited I'm not sure how can I help in there. This happens since something was modified recently in Innodb. It does not happen with anything else. IF there is a founded suspicion that something (what) does not work, I wholehearteadly welcome this analysis it is not the first time Innodb_fast_shutdown is being used in tests C:\work\10.3\mysql-test>git grep innodb_fast_shutdown | findstr .test | wc -l 94

Elena Stepanova added a comment - 2021-10-04 10:26 Various tests have been failing with the same assertion failure for a long time ( MDEV-13644 ), although I don't know if it's related to slow shutdown and/or otherwise is the same problem.

Marko Mäkelä added a comment - 2021-10-12 05:19 While the tests that have been named in MDEV-13644 do not involve shutdown with innodb_fast_shutdown=0 , I believe that these failures could share a root cause with that. I think that the correct assignee of this issue is the author of thd_destructor_proxy .

Sergei Golubchik added a comment - 2021-11-03 13:48 This is what's happening. The server starts shutting down, it sends a signal to all threads, including thd_destructor_proxy , the latter starts srv_purge_shutdown() . But InnoDB is too busy purging, all workers purge something and don't react immediately. The server does this: /* Give threads time to die.   In 5.5, this was waiting 100 rounds @ 20 milliseconds/round, so as little as 2 seconds, depending on thread scheduling.   From 10.0, we increase this to 1000 rounds / 20 seconds. The rationale is that on a server with heavy I/O load, it is quite possible for eg. an fsync() of the binlog or whatever to cause something like LOCK_log to be held for more than 2 seconds. We do not want to force kill threads in such cases, if it can be avoided. Note that normally, the wait will be much smaller than even 2 seconds, this is only a safety fallback against stuck threads so server shutdown is not held up forever. */ DBUG_PRINT( "info" , ( "thread_count: %d" , thread_count));   for ( int i= 0; *( volatile int32*) &thread_count && i < 1000; i++) my_sleep(20000); But in this test it's not enough and the server starts unlinking threads one by one (with threads.get() ) and forcibly close their open connections. InnoDB threads have no connection to close, but they're unlinked too, and that triggers an assert when they finally detect the shutdown request and try to unlink, asserting first that they're still linked.