From: Dmitry Lenev
Date: October 21 2010 5:45am
Subject: bzr push into mysql-5.5-runtime branch (Dmitry.Lenev:3170 to 3171)
List-Archive: http://lists.mysql.com/commits/121434
Message-Id: <20101021054529.C27652F0E23@mockturtle>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 3171 Dmitry Lenev	2010-10-21
      More changes to draft patch refactoring global read
      lock implementation. Makes GRL yet another type of
      metadata lock and thus exposes it to deadlock detector
      in MDL subsystem.
      
      Solves bugs #54673 "It takes too long to get readlock for
      'FLUSH TABLES WITH READ LOCK'" and #57006 "Deadlock between
      HANDLER and FLUSH TABLES WITH READ LOCK".
      
      Work-in-progress. Remove resolved questions.

    modified:
      mysql-test/r/flush_read_lock.result
      mysql-test/r/mdl_sync.result
      mysql-test/t/flush_read_lock.test
      mysql-test/t/mdl_sync.test
      sql/sql_parse.cc
 3170 Konstantin Osipov	2010-10-21
      Bug#54673 It takes too long to get readlock for 
      'FLUSH TABLES WITH READ LOCK'.
      Review fixes.

    modified:
      mysql-test/include/check_ftwrl_compatible.inc
      mysql-test/include/check_ftwrl_incompatible.inc
=== modified file 'mysql-test/r/flush_read_lock.result'
--- a/mysql-test/r/flush_read_lock.result	2010-10-20 07:52:42 +0000
+++ b/mysql-test/r/flush_read_lock.result	2010-10-21 05:43:57 +0000
@@ -103,7 +103,6 @@ Success: FTWRL is blocked when 'alter ev
 #
 # 2) ANALYZE TABLE statement is compatible with FTWRL.
 #
-# QQ: Is this a correct behavior?
 Success: Was able to run 'analyze table t1_base' under FTWRL.
 Success: Was able to run 'analyze table t1_base' with FTWRL active in another connection.
 Success: Was able to run FTWRL while 'analyze table t1_base' was active in another connection.

=== modified file 'mysql-test/r/mdl_sync.result'
--- a/mysql-test/r/mdl_sync.result	2010-10-18 12:33:49 +0000
+++ b/mysql-test/r/mdl_sync.result	2010-10-21 05:43:57 +0000
@@ -2488,21 +2488,17 @@ SET DEBUG_SYNC= 'now WAIT_FOR table_open
 # and let DROP PROCEDURE continue
 SET DEBUG_SYNC= 'mdl_acquire_lock_wait SIGNAL grlwait';
 FLUSH TABLES WITH READ LOCK;
-# Connection 2
+# Connection 1
 # Once FLUSH TABLES WITH READ LOCK starts waiting
 # DROP PROCEDURE will be waked up and will drop
 # procedure. Global read lock will be granted after
-# this point. After that DROP PROCEDURE will block
-# due to GRL during attempt to auto-magically revoke
-# privileges. This is expected as we treat these two 
-# steps as a separate statements.
-#
-# QQ: This doesn't seem right and IMO breaks binary
-#     logging!
-# Ublock second part of DROP PROCEDURE.
+# this statement ends.
+#
+# Reaping DROP PROCEDURE.
+# Connection 2
+# Reaping FTWRL.
 UNLOCK TABLES;
 # Connection 1
-# Connection 1
 SET DEBUG_SYNC= 'RESET';
 #
 # Bug#50786 Assertion `thd->mdl_context.trans_sentinel() == __null' 

=== modified file 'mysql-test/t/flush_read_lock.test'
--- a/mysql-test/t/flush_read_lock.test	2010-10-20 07:52:42 +0000
+++ b/mysql-test/t/flush_read_lock.test	2010-10-21 05:43:57 +0000
@@ -143,7 +143,6 @@ let $cleanup_stmt1= alter event e1 comme
 --echo #
 --echo # 2) ANALYZE TABLE statement is compatible with FTWRL.
 --echo #
---echo # QQ: Is this a correct behavior?
 let $statement= analyze table t1_base;
 let $cleanup_stmt= ;
 --source include/check_ftwrl_compatible.inc

=== modified file 'mysql-test/t/mdl_sync.test'
--- a/mysql-test/t/mdl_sync.test	2010-10-18 12:33:49 +0000
+++ b/mysql-test/t/mdl_sync.test	2010-10-21 05:43:57 +0000
@@ -3692,25 +3692,21 @@ SET DEBUG_SYNC= 'now WAIT_FOR table_open
 SET DEBUG_SYNC= 'mdl_acquire_lock_wait SIGNAL grlwait';
 --send FLUSH TABLES WITH READ LOCK
 
---echo # Connection 2
-connection con2;
+--echo # Connection 1
+connection default;
 --echo # Once FLUSH TABLES WITH READ LOCK starts waiting
 --echo # DROP PROCEDURE will be waked up and will drop
 --echo # procedure. Global read lock will be granted after
---echo # this point. After that DROP PROCEDURE will block
---echo # due to GRL during attempt to auto-magically revoke
---echo # privileges. This is expected as we treat these two 
---echo # steps as a separate statements.
+--echo # this statement ends.
 --echo #
---echo # QQ: This doesn't seem right and IMO breaks binary
---echo #     logging!
+--echo # Reaping DROP PROCEDURE.
 --reap
---echo # Ublock second part of DROP PROCEDURE.
-UNLOCK TABLES;
 
---echo # Connection 1
-connection default;
+--echo # Connection 2
+connection con2;
+--echo # Reaping FTWRL.
 --reap
+UNLOCK TABLES;
 
 --echo # Connection 1
 connection default;

=== modified file 'sql/sql_parse.cc'
--- a/sql/sql_parse.cc	2010-10-20 07:52:42 +0000
+++ b/sql/sql_parse.cc	2010-10-21 05:43:57 +0000
@@ -363,7 +363,6 @@ void init_update_queries(void)
   sql_command_flags[SQLCOM_DROP_USER]=         CF_CHANGES_DATA;
   sql_command_flags[SQLCOM_GRANT]=             CF_CHANGES_DATA;
   sql_command_flags[SQLCOM_REVOKE]=            CF_CHANGES_DATA;
-  // QQ Looks somewhat strange but is not changed...
   sql_command_flags[SQLCOM_OPTIMIZE]=          CF_CHANGES_DATA;
   sql_command_flags[SQLCOM_CREATE_FUNCTION]=   CF_CHANGES_DATA;
   sql_command_flags[SQLCOM_CREATE_PROCEDURE]=  CF_CHANGES_DATA | CF_AUTO_COMMIT_TRANS |

No bundle (reason: useless for push emails).