Bug #57165 LOCK TABLE IN EXCLUSIVE MODE ignores FLUSH TABLES WITH READ LOCK

• Submitted: 1 Oct 2010 12:51
• Modified: 4 Apr 2011 18:53
• Reporter: Konstantin Osipov (OCA)
• Status: Won't fix
• Category: MySQL Server: Locking
• Severity: S3 (Non-critical)
• Version: mysql-next-mr-wl3561
• OS: Any
• CPU Architecture: Any

[1 Oct 2010 12:51] Konstantin Osipov

Description:
LOCK TABLES IN EXCLUSIVE MODE ingores FLUSH TABLES WITH GLOBAL READ LOCK.
I.e. they are mutually compatible. This leads to a deadlock if the subject table is later used.

How to repeat:
-- In connection 1:

set autocommit=off;
drop table t1;
create table t1 (a int) engine=innodb;
begin;
lock table t1 in exclusive mode;

-- In connection 2:
flush tables with read lock;

-- observe the above statement go through
-- In connection 1:
update t1 set a=1; -- observe a hang

Suggested fix:
Pull from next-mr and correctly merge. The patches in next-mr take scoped metadata locks for LOCK TABLE, which are mutually exclusive with the global shared metadata lock taken by FTWRL.

[1 Oct 2010 12:56] Konstantin Osipov

Please make sure the two statements are mutually exclusive regardless of which of them comes in first.

[1 Oct 2010 17:32] Valeriy Kravchuk

Verified as described with current mysql-next-mr-wl3561 tree on Mac OS X.

[4 Apr 2011 18:53] Dmitry Lenev

Since was bug was reported against feature tree for WL#3561 "Transactional
LOCK TABLES" and this worklog got cancelled I am closing this bug as "Won't
fix".