bzr commit into mysql-5.5 branch (jon.hauglid:3219) Bug#57649

[Jon Olav Hauglid]

#At file:///export/home/x/mysql-5.5-bug57649/ based on revid:saikumar.v@stripped

 3219 Jon Olav Hauglid	2011-01-07
      Bug #57649 FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads
                 to assert failure.
      
      This is a draft patch.
      
      The triggered assert checks that a connection already holds a global
      intention exclusive metadata lock if it tries to acquire an exclusive
      metadata lock. It was triggered by a connection first executing
      FLUSH TABLES <list> WITH READ LOCK and then later trying to execute
      a statement which caused an exclusive metadata lock to be acquired
      (e.g. FLUSH TABLES, CREATE TRIGGER).
      
      The cause of the problem is that FLUSH TABLES <list> WITH READ LOCK
      does not acquire a global intention exclusive metadata lock. This
      is done to make FLUSH TABLES <list> WITH READ LOCK compatible with
      FLUSH TABLES WITH READ LOCK. If FLUSH TABLES <list> WITH READ LOCK
      had acquired a global intention exclusive metadata lock, it would
      have caused FLUSH TABLES WITH READ LOCK (from other connections)
      to be blocked.
      
      This patch fixes the problem by acquiring a global intention
      exclusive metadata lock for statements trying to upgrade an
      existing metadata lock to exclusive inside LOCK TABLES mode if
      a global intention exclusive metadata lock is not already held.
      
      Test case added to flush.test.

    modified:
      mysql-test/r/flush.result
      mysql-test/t/flush.test
      sql/sql_base.cc
=== modified file 'mysql-test/r/flush.result'
--- a/mysql-test/r/flush.result	2010-11-11 17:11:05 +0000
+++ b/mysql-test/r/flush.result	2011-01-07 11:40:37 +0000
@@ -451,3 +451,13 @@ unlock tables;
 handler t1 close;
 # Cleanup.
 drop tables t1, t2;
+#
+# Bug#57649 FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads
+#           to assert failure.
+#
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1 (a INT);
+FLUSH TABLES t1 WITH READ LOCK;
+FLUSH TABLES;
+UNLOCK TABLES;
+DROP TABLE t1;

=== modified file 'mysql-test/t/flush.test'
--- a/mysql-test/t/flush.test	2010-11-11 17:11:05 +0000
+++ b/mysql-test/t/flush.test	2011-01-07 11:40:37 +0000
@@ -644,3 +644,21 @@ disconnect con2;
 --source include/wait_until_disconnected.inc
 connection default;
 drop tables t1, t2;
+
+
+--echo #
+--echo # Bug#57649 FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads
+--echo #           to assert failure.
+--echo #
+
+--disable_warnings
+DROP TABLE IF EXISTS t1;
+--enable_warnings
+
+CREATE TABLE t1 (a INT);
+FLUSH TABLES t1 WITH READ LOCK;
+# This triggered the assertion
+FLUSH TABLES;
+
+UNLOCK TABLES;
+DROP TABLE t1;

=== modified file 'sql/sql_base.cc'
--- a/sql/sql_base.cc	2010-12-29 00:26:31 +0000
+++ b/sql/sql_base.cc	2011-01-07 11:40:37 +0000
@@ -2215,6 +2215,18 @@ bool wait_while_table_is_used(THD *thd,
                        table->s->table_name.str, (ulong) table->s,
                        table->db_stat, table->s->version));
 
+  if (thd->locked_tables_mode &&
+      !thd->mdl_context.is_lock_owner(MDL_key::GLOBAL, "", "",
+                                      MDL_INTENTION_EXCLUSIVE))
+  {
+    MDL_request global_request;
+    global_request.init(MDL_key::GLOBAL, "", "", MDL_INTENTION_EXCLUSIVE,
+                        MDL_STATEMENT);
+    if (thd->mdl_context.acquire_lock(&global_request,
+                                      thd->variables.lock_wait_timeout))
+      DBUG_RETURN(TRUE);
+  }
+
   if (thd->mdl_context.upgrade_shared_lock_to_exclusive(
              table->mdl_ticket, thd->variables.lock_wait_timeout))
     DBUG_RETURN(TRUE);


Attachment: [text/bzr-bundle] bzr/[e-mail]