From 97e07d7a1fba7d4ba5730b06fd0f1250437e2ca4 Mon Sep 17 00:00:00 2001 From: Jon Olav Hauglid Date: Wed, 18 Nov 2009 10:02:21 +0100 Subject: Bug #47682 strange behaviour of INSERT DELAYED The problem was a "self-deadlock" if the connection issuing INSERT DELAYED had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES mode active. The table being inserted into had to be different from the table(s) locked by LOCK TABLES. For INSERT DELAYED, the connection thread waits until the handler thread has opened and locked its table before returning. But since the global read lock was active, the handler thread would be unable to lock and would wait for the global read lock to go away. So the handler thread would be waiting for the connection thread to release the global read lock while the connection thread was waiting for the handler thread to lock the table. This gave a "self-deadlock" (same connection, different threads). The deadlock would only happen if we also had LOCK TABLES mode since the INSERT otherwise will try to get protection against global read lock before starting the handler thread. It will then notice that the global read lock is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK. This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK also if we are inside LOCK TABLES mode. Test case added to delayed.test. --- mysql-test/t/delayed.test | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'mysql-test/t/delayed.test') diff --git a/mysql-test/t/delayed.test b/mysql-test/t/delayed.test index 94ad22b80d0..99ec99803a7 100644 --- a/mysql-test/t/delayed.test +++ b/mysql-test/t/delayed.test @@ -328,4 +328,26 @@ drop table t1; set global low_priority_updates = @old_delayed_updates; + +--echo # +--echo # Bug #47682 strange behaviour of INSERT DELAYED +--echo # + +--disable_warnings +DROP TABLE IF EXISTS t1, t2; +--enable_warnings + +CREATE TABLE t1 (f1 integer); +CREATE TABLE t2 (f1 integer); + +FLUSH TABLES WITH READ LOCK; +LOCK TABLES t1 READ; + +--error ER_CANT_UPDATE_WITH_READLOCK +INSERT DELAYED INTO t2 VALUES (1); + +UNLOCK TABLES; +DROP TABLE t1, t2; + + --echo End of 5.1 tests -- cgit v1.2.1 From 45a0a900af336d031b9fc29815af916fb28ceda8 Mon Sep 17 00:00:00 2001 From: Jon Olav Hauglid Date: Wed, 18 Nov 2009 13:49:45 +0100 Subject: Postfix for Bug #47682 strange behaviour of INSERT DELAYED Fixed a problem with the test case when executed with ps-protocol. There the conflicing lock would be noticed during prepare, not during execution of the insert - leading to a different (but equally appropriate) error message. --- mysql-test/t/delayed.test | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'mysql-test/t/delayed.test') diff --git a/mysql-test/t/delayed.test b/mysql-test/t/delayed.test index 99ec99803a7..689341391c9 100644 --- a/mysql-test/t/delayed.test +++ b/mysql-test/t/delayed.test @@ -343,7 +343,9 @@ CREATE TABLE t2 (f1 integer); FLUSH TABLES WITH READ LOCK; LOCK TABLES t1 READ; ---error ER_CANT_UPDATE_WITH_READLOCK +# ER_CANT_UPDATE_WITH_READLOCK with normal execution +# ER_TABLE_NOT_LOCKED when executed as prepared statement +--error ER_CANT_UPDATE_WITH_READLOCK, ER_TABLE_NOT_LOCKED INSERT DELAYED INTO t2 VALUES (1); UNLOCK TABLES; -- cgit v1.2.1