Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5
-
None
Description
There is semaphore timeout, found by Matthias during MDEV-28709 testing(10.5).
The timeout is on "mutex_enter(&dict_sys.mutex)" in "dict_table_open_on_name()".
This mutex was acquired by the thread which executes "while ((table_name = dict_get_first_table_name_in_db(name)))" loop in "row_drop_database_for_mysql()" under that mutex. And execution is so long that semaphore timeout was caught.
The loop does not make any progress, as "dict_get_first_table_name_in_db(name)" constantly returns the same table_name after "row_drop_table_for_mysql(table_name, ...)" returned DB_SUCCESS for it. Table name is "cool_down/#sql-ib22", so it's tmp table. DICT_TF2_TEMPORARY is not set for the table, that is why "row_drop_table_for_mysql(table_name, ...)" pushes the table in background table drop list and returns DB_SUCCESS.
row_drop_tables_for_mysql_in_background() tries to open the table with dict_table_open_on_id() , which, in turns, requests dict_sys.mutex and can't acquire it, as row_drop_database_for_mysql() holds it.
So, we have deadlock, which can't be detected with sync_array_detect_deadlock() , as row_drop_database_for_mysql() waits state changes from row_drop_tables_for_mysql_in_background() , which is waiting for the mutex held by row_drop_database_for_mysql() .
Attachments
Issue Links
- relates to
-
MDEV-24258 Merge dict_sys.mutex into dict_sys.latch
- Closed
-
MDEV-25506 Atomic DDL: .frm file is removed and orphan InnoDB tablespace is left behind upon crash recovery
- Closed
-
MDEV-25691 Simplify handlerton::drop_database for InnoDB
- Closed