-
unknown authored
The order of acquiring LOCK_mysql_create_db and wait_if_global_read_lock() was wrong. It could happen that a thread held LOCK_mysql_create_db while waiting for the global read lock to be released. The thread with the global read lock could try to administrate a database too. It would first try to lock LOCK_mysql_create_db and hang... The check if the current thread has the global read lock is done in wait_if_global_read_lock(), which could not be reached because of the hang in LOCK_mysql_create_db. Now I exchanged the order of acquiring LOCK_mysql_create_db and wait_if_global_read_lock(). This makes wait_if_global_read_lock() fail with an error message for the thread with the global read lock. No deadlock happens. mysql-test/r/lock_multi.result: Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock The test result mysql-test/t/lock_multi.test: Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock The test case sql/sql_db.cc: Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock Exchanged the order of acquiring LOCK_mysql_create_db and wait_if_global_read_lock().
4f8407b6