Yuchen Pei added a comment - 2023-01-13 05:54 - edited Looking more into it, the sequence of events is as follows (using commit fdcfc25) 1. The main thread inits the spider plugin (sql/mysqld.cc:5775) a number of (default 10) threads are created during the spider plugin init ( spider_db_init() ) to run spider_table_bg_sts_action() , later a number of (default 10) threads are created to run spider_table_bg_crd_action() . The two functions are almost identical, with the main difference being the sts function having an extra bit of init_command if statment: if ( thread ->init_command) { ... if (!(*spd_mysqld_server_started) && !thd->killed) { ... if (!(*spd_mysqld_server_started) && !thd->killed) { pthread_cond_wait(spd_COND_server_started, spd_LOCK_server_started); // [1] } ... } while (spider_init_queries[i].length && !thd->killed) { dispatch_command(COM_QUERY, thd, spider_init_queries[i].str, (uint) spider_init_queries[i].length, FALSE, FALSE); ... ++i; } ... thread ->init_command = FALSE; pthread_cond_broadcast(& thread ->sync_cond); } the only thread with init_command set to true is the first sts thread, and it is only set false in the snippet above, after the server starts. If the server has not started, it continues to wait (see [1] above, where spd_COND_server_started is a pointer to cond_server_started) 2. The main thread tries to abort by calling unireg_abort() (with exit code 0) after finding wsrep_recover (line 5797) during the aborting, spider decides to free all the sts thread in spider_free_sts_threads() . All but one can be freed. No prize for guessing which one cannot be freed, as it holds the lock while waiting for the server to start judging from the backtrace at [2] , MDEV-22979 is tripped at the same place, as it calls unireg_abort() too before the server starts (line 5868) judging from the comment at [3] [4] , MDEV-27233 is slightly different, as it is spider_create_handler (instead of spider_free_sts_threads() ) trying to lock a mutex held by the first sts thread. The problem seems more bizarre due to the unlikely and the same check (thread->init_command), making it look like an inevitable deadlock ( [5] below). handler* spider_create_handler( handlerton *hton, TABLE_SHARE *table, MEM_ROOT *mem_root ) { ... SPIDER_THREAD * thread = &spider_table_sts_threads[0]; if (unlikely( thread ->init_command)) { ... /* wait for finishing init_command */ pthread_mutex_lock(& thread ->mutex); // [5] } .. 3. The server would start had none of the unireg_abort() been called (line 5935): mysqld_server_started= 1; mysql_cond_broadcast(&COND_server_started); [2] https://jira.mariadb.org/browse/MDEV-22979?focusedCommentId=158235&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-158235 [3] https://jira.mariadb.org/browse/MDEV-27233?focusedCommentId=209160&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-209160 [4] https://jira.mariadb.org/browse/MDEV-27233?focusedCommentId=209175&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-209175 Based on this analysis, with --plugin-load-add=ha_spider.so , any call to unireg_abort() between the init of plugins (sql/mysqld.cc:5775) and the start of the server (sql/mysqld.cc:5935) will cause a hang. In this sense the present ticket is almost a duplicate of MDEV-22979 , and a fix should also fix that one. It would be ideal if a fix for this ticket can also fix MDEV-27233 , but it is not clear whether a fix naturally works for all three tickets, or naturally splits into two that fixes this+22979 and 27233 separately.