bzr commit into mysql-5.6-next-mr branch (dlenev:3062) Bug#46272

[Dmitry Lenev]

#At file:///home/dlenev/src/bzr/mysql-next-4284-nl-review/ based on revid:kostja@stripped

 3062 Dmitry Lenev	2010-01-27
      Tentative patch implementing new type-of-operation-aware metadata locks.
      Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug
      #37346 "innodb does not detect deadlock between update and alter table".
      
      After review fixes in progress.

    modified:
      mysql-test/r/events_2.result
      mysql-test/r/mdl_sync.result
      mysql-test/t/events_2.test
      mysql-test/t/mdl_sync.test
      sql/mdl.cc
=== modified file 'mysql-test/r/events_2.result'
--- a/mysql-test/r/events_2.result	2010-01-22 05:53:57 +0000
+++ b/mysql-test/r/events_2.result	2010-01-27 08:51:28 +0000
@@ -203,14 +203,24 @@ ERROR HY000: Table 'event' was locked wi
 drop event e1;
 ERROR HY000: Table 'event' was locked with a READ lock and can't be updated
 unlock tables;
-#
-# QQ: Should we somehow detect deadlock caused by SHOW CREATE EVENT
-#     and SELECT FROM I_S.EVENTS below and do something about it?
-#     Alternatively we can try not to use separate MDL_context for
-#     tables and thus avoid deadlock in this case...
-#
-Make sure we have left no events 
+lock table t1 read, mysql.event write;
+ERROR HY000: You can't combine write-locking of system tables with other tables or lock types
+lock table t1 write, mysql.event write;
+ERROR HY000: You can't combine write-locking of system tables with other tables or lock types
+lock table mysql.event write;
+show create event e1;
+Event	sql_mode	time_zone	Create Event	character_set_client	collation_connection	Database Collation
+e1		SYSTEM	CREATE DEFINER=`root`@`localhost` EVENT `e1` ON SCHEDULE EVERY 10 HOUR STARTS '#' ON COMPLETION NOT PRESERVE ENABLE DO select 1	utf8	utf8_general_ci	latin1_swedish_ci
+select event_name from information_schema.events;
+event_name
+e1
+create event e2 on schedule every 10 hour do select 1;
+alter event e2 disable;
+alter event e2 rename to e3;
+drop event e3;
 drop event e1;
+unlock tables;
+Make sure we have left no events 
 select event_name from information_schema.events;
 event_name
 

=== modified file 'mysql-test/r/mdl_sync.result'
--- a/mysql-test/r/mdl_sync.result	2010-01-22 05:53:57 +0000
+++ b/mysql-test/r/mdl_sync.result	2010-01-27 08:51:28 +0000
@@ -952,23 +952,18 @@ lock table t1 write;;
 # 
 # Switching to connection 'mdl_con1'.
 # Check that LOCK TABLE is waiting with pending UNRW lock.
-# Check that UNW is incompatible with pending UNRW
-# QQ: Should this be changed, to avoid starvation of ALTER TABLE?
-# Sending:
-alter table t1 add primary key (c1);;
+# Check that UNW is compatible with pending UNRW
+# So ALTER TABLE statements are not starved by LOCK TABLEs.
+alter table t1 add primary key (c1);
+ERROR 23000: Duplicate entry '1' for key 'PRIMARY'
 # 
 # Switching to connection 'mdl_con2'.
-# Check that the above ALTER is blocked because of pending UNRW lock.
 # Unblock LOCK TABLE.
 commit;
 # 
 # Switching to connection 'default'.
 # Reaping LOCK TABLE.
 unlock tables;
-# 
-# Switching to connection 'mdl_con1'.
-# Reaping ALTER TABLE.
-ERROR 23000: Duplicate entry '1' for key 'PRIMARY'
 #
 # We can't do similar check for UNRW and X locks because
 # they will also be blocked by active SR lock.

=== modified file 'mysql-test/t/events_2.test'
--- a/mysql-test/t/events_2.test	2010-01-22 05:53:57 +0000
+++ b/mysql-test/t/events_2.test	2010-01-27 08:51:28 +0000
@@ -283,13 +283,6 @@ drop event e2;
 --error ER_TABLE_NOT_LOCKED_FOR_WRITE
 drop event e1;
 unlock tables;
---echo #
---echo # QQ: Should we somehow detect deadlock caused by SHOW CREATE EVENT
---echo #     and SELECT FROM I_S.EVENTS below and do something about it?
---echo #     Alternatively we can try not to use separate MDL_context for
---echo #     tables and thus avoid deadlock in this case...
---echo #
---disable_parsing
 #
 --error ER_WRONG_LOCK_OF_SYSTEM_TABLE
 lock table t1 read, mysql.event write;
@@ -307,9 +300,7 @@ alter event e2 rename to e3;
 drop event e3;
 drop event e1;
 unlock tables;
---enable_parsing
 --echo Make sure we have left no events 
-drop event e1;
 select event_name from information_schema.events;
 --echo
 --echo Events in sub-statements, events and prelocking

=== modified file 'mysql-test/t/mdl_sync.test'
--- a/mysql-test/t/mdl_sync.test	2010-01-22 05:53:57 +0000
+++ b/mysql-test/t/mdl_sync.test	2010-01-27 08:51:28 +0000
@@ -1338,18 +1338,13 @@ let $wait_condition=
 select count(*) = 1 from information_schema.processlist
 where state = "Waiting for table" and info = "lock table t1 write";
 --source include/wait_condition.inc
---echo # Check that UNW is incompatible with pending UNRW
---echo # QQ: Should this be changed, to avoid starvation of ALTER TABLE?
---echo # Sending:
---send alter table t1 add primary key (c1);
+--echo # Check that UNW is compatible with pending UNRW
+--echo # So ALTER TABLE statements are not starved by LOCK TABLEs.
+--error ER_DUP_ENTRY
+alter table t1 add primary key (c1);
 --echo # 
 --echo # Switching to connection 'mdl_con2'.
 connection mdl_con2;
---echo # Check that the above ALTER is blocked because of pending UNRW lock.
-let $wait_condition=
-select count(*) = 1 from information_schema.processlist
-where state = "Waiting for table" and info = "alter table t1 add primary key (c1)";
---source include/wait_condition.inc
 --echo # Unblock LOCK TABLE.
 commit;
 --echo # 
@@ -1358,12 +1353,6 @@ connection default;
 --echo # Reaping LOCK TABLE.
 --reap
 unlock tables;
---echo # 
---echo # Switching to connection 'mdl_con1'.
-connection mdl_con1;
---echo # Reaping ALTER TABLE.
---error ER_DUP_ENTRY
---reap
 --echo #
 --echo # We can't do similar check for UNRW and X locks because
 --echo # they will also be blocked by active SR lock.

=== modified file 'sql/mdl.cc'
--- a/sql/mdl.cc	2010-01-26 18:22:10 +0000
+++ b/sql/mdl.cc	2010-01-27 08:51:28 +0000
@@ -874,9 +874,9 @@ const uchar MDL_global_lock::m_waiting_i
   SH        | +   +   +   +   +    +    -  | +   +   +   +   +     +   + |
   SR        | +   +   +   +   +    -    -  | +   +   +   +   +     -   - |
   SW        | +   +   +   +   -    -    -  | +   +   +   +   -     -   - |
-  UNW       | +   +   +   -   -    -    -  | +   +   +   +   +?    -   -?|
-  UNRW      | +   +   -   -   -    -    -  | +   +   +   +   +?    +   -?|
-  X         | -   -   -   -   -    -    -  | +   +   +   +   +?    +   +?|
+  UNW       | +   +   +   -   -    -    -  | +   +   +   +   +     +   - |
+  UNRW      | +   +   -   -   -    -    -  | +   +   +   +   +     +   - |
+  X         | -   -   -   -   -    -    -  | +   +   +   +   +     +   + |
   UNW -> X  | -   -   -   0   0    0    0  | +   +   +   +   +     +   + |
   UNRW -> X | -   -   0   0   0    0    0  | +   +   +   +   +     +   + |
 
@@ -884,8 +884,6 @@ const uchar MDL_global_lock::m_waiting_i
         "-" -- means that request can't be satisfied and should wait
         "0" -- means impossible situation which will trigger assert
 
-  ?) Choice for these cases is actually questionable. QQ?
-
   @note In cases then current context already has "stronger" type
         of lock on the object it will be automatically granted
         thanks to usage of the MDL_context::find_ticket() method.
@@ -918,8 +916,8 @@ const uchar MDL_object_lock::m_waiting_i
   MDL_BIT(MDL_EXCLUSIVE) | MDL_BIT(MDL_UPGRADABLE_NO_READ_WRITE),
   MDL_BIT(MDL_EXCLUSIVE) | MDL_BIT(MDL_UPGRADABLE_NO_READ_WRITE) |
     MDL_BIT(MDL_UPGRADABLE_NO_WRITE),
-  MDL_BIT(MDL_EXCLUSIVE) | MDL_BIT(MDL_UPGRADABLE_NO_READ_WRITE),
-  MDL_BIT(MDL_EXCLUSIVE) ,
+  MDL_BIT(MDL_EXCLUSIVE),
+  MDL_BIT(MDL_EXCLUSIVE),
   0
 };
 


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