Jon Olav Hauglid db1888b53c Bug #49988 MDL deadlocks with mysql_create_db, reload_acl_and_cache ...

This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection
and DROP DATABASE in another. It only happened if the table locked by 
LOCK TABLES was in the database to be dropped. The deadlock is similar
to the one in Bug#48940, but with LOCK TABLES instead of an active
transaction.

The order of events needed to trigger the deadlock was:
1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now
have a metadata lock on the table name.
2) Connection 2 issues DROP DATABASE db1. This will wait inside
the MDL subsystem for the lock on db1.t1 to go away. While waiting, it
will hold the LOCK_mysql_create_db mutex.
3) Connection 1 issues CREATE DATABASE (database name irrelevant).
This will hang trying to lock the same mutex. Since this is the connection
holding the metadata lock blocking Connection 2, we have a deadlock.

This deadlock would also happen for earlier trees without MDL, but 
there DROP DATABASE would wait for a table to be removed from the
table definition cache.

This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES
mode. In the example above, this prevents Connection 1 from hanging trying
to get the LOCK_mysql_create_db mutex. Note that other commands that use
LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in 
LOCK TABLES mode.

Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode.

Test case added to schema.test.

2010-01-12 16:15:21 +01:00

2.4 KiB

Raw Blame History

View Raw