------------------------------------------------------------
revno: 2617.68.10
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-next-bg46673
timestamp: Tue 2009-09-01 19:57:05 +0400
message:
  Fix for bug #46673 "Deadlock between FLUSH TABLES WITH READ LOCK and DML".

  Deadlocks occured when one concurrently executed transactions with
  several statements modifying data and FLUSH TABLES WITH READ LOCK
  statement or SET READ_ONLY=1 statement.

  These deadlocks were introduced by the patch for WL 4284: "Transactional
  DDL locking"/Bug 989: "If DROP TABLE while there's an active transaction,
  wrong binlog order" which has changed FLUSH TABLES WITH READ LOCK/SET
  READ_ONLY=1 to wait for pending transactions.
  What happened was that FLUSH TABLES WITH READ LOCK blocked all further
  statements changing tables by setting global_read_lock global variable
  and has started waiting for all pending transactions to complete.
  Then one of those transactions tried to executed DML, detected that
  global_read_lock non-zero and tried to wait until global read lock will
  be released (i.e. global_read_lock becomes 0), indeed, this led to a
  deadlock.

  Proper solution for this problem should probably involve full integration
  of global read lock with metadata locking subsystem (which will allow to
  implement waiting for pending transactions without blocking DML in them).
  But since it requires significant changes another, short-term solution
  for the problem is implemented in this patch.

  Basically, this patch restores behavior of FLUSH TABLES WITH READ LOCK/
  SET READ_ONLY=1 before the patch for WL 4284/bug 989. By ensuring that
  extra references to TABLE_SHARE are not stored for active metadata locks
  it changes these statements not to wait for pending transactions.
  As result deadlock is eliminated.
  Note that this does not change the fact that active FLUSH TABLES WITH
  READ LOCK lock or SET READ_ONLY=1 prevent modifications to tables as
  they also block transaction commits.