MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Jon Olav Hauglid Date:January 8 2010 1:28pm
Subject:bzr commit into mysql-6.0-codebase branch (jon.hauglid:3747) Bug#48538
View as plain text  
#At file:///export/home/z/mysql-6.0-codebase-4284-bug48538/ based on revid:dlenev@stripped

 3747 Jon Olav Hauglid	2010-01-08 [merge]
      Manual merge from mysql-next-4284 of fix for Bug #48538 
      "Assertion in thr_lock() on LOAD DATA CONCURRENT INFILE".

    modified:
      mysql-test/r/lock.result
      mysql-test/t/lock.test
      mysys/thr_lock.c
=== modified file 'mysql-test/r/lock.result'
--- a/mysql-test/r/lock.result	2009-12-11 15:44:05 +0000
+++ b/mysql-test/r/lock.result	2010-01-08 13:28:06 +0000
@@ -356,5 +356,18 @@ ERROR HY000: Can't execute the given com
 UNLOCK TABLES;
 DROP TABLE t1;
 #
+# Simplified test for bug #48538 "Assertion in thr_lock() on LOAD DATA
+# CONCURRENT INFILE".
+#
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1 (f1 INT, f2 INT) ENGINE = MEMORY;
+CREATE TRIGGER t1_ai AFTER INSERT ON t1 FOR EACH ROW 
+UPDATE LOW_PRIORITY t1 SET f2 = 7;
+# Statement below should fail with ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG
+# error instead of failing on assertion in table-level locking subsystem.
+INSERT INTO t1(f1) VALUES(0);
+ERROR HY000: Can't update table 't1' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.
+DROP TABLE t1;
+#
 # End of 6.0 tests.
 #

=== modified file 'mysql-test/t/lock.test'
--- a/mysql-test/t/lock.test	2009-12-11 15:44:05 +0000
+++ b/mysql-test/t/lock.test	2010-01-08 13:28:06 +0000
@@ -441,5 +441,26 @@ DROP TABLE t1;
 
 
 --echo #
+--echo # Simplified test for bug #48538 "Assertion in thr_lock() on LOAD DATA
+--echo # CONCURRENT INFILE".
+--echo #
+
+--disable_warnings
+DROP TABLE IF EXISTS t1;
+--enable_warnings
+
+CREATE TABLE t1 (f1 INT, f2 INT) ENGINE = MEMORY;
+CREATE TRIGGER t1_ai AFTER INSERT ON t1 FOR EACH ROW 
+  UPDATE LOW_PRIORITY t1 SET f2 = 7; 
+
+--echo # Statement below should fail with ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG
+--echo # error instead of failing on assertion in table-level locking subsystem.
+--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG
+INSERT INTO t1(f1) VALUES(0);
+
+DROP TABLE t1;
+
+
+--echo #
 --echo # End of 6.0 tests.
 --echo #

=== modified file 'mysys/thr_lock.c'
--- a/mysys/thr_lock.c	2009-12-11 15:44:05 +0000
+++ b/mysys/thr_lock.c	2010-01-08 13:28:06 +0000
@@ -698,16 +698,25 @@ thr_lock(THR_LOCK_DATA *data, THR_LOCK_O
         TL_WRITE_ALLOW_WRITE or TL_WRITE_CONCURRENT_INSERT
 
         Note that, since lock requests for the same table are sorted in
-        such way that requests with higher thr_lock_type value come first,
-        lock being requested usually has equal or "weaker" type than one
-        which thread might have already acquired.
-        The exceptions are situations when:
-          - old lock type is TL_WRITE_CONCURRENT_INSERT and new lock type
-            is TL_WRITE_ALLOW_READ or TL_WRITE_ALLOW_WRITE
-          - old lock type is TL_WRITE_ALLOW_READ and new lock type is
-            TL_WRITE_ALLOW_WRITE
-          - when old lock type is TL_WRITE_DELAYED
-        But these should never happen within MySQL.
+        such way that requests with higher thr_lock_type value come first
+        (with one exception (*)), lock being requested usually (**) has
+        equal or "weaker" type than one which thread might have already
+        acquired.
+        *)  The only exception to this rule is case when type of old lock
+            is TL_WRITE_LOW_PRIORITY and type of new lock is changed inside
+            of thr_lock() from TL_WRITE_CONCURRENT_INSERT to TL_WRITE since
+            engine turns out to be not supporting concurrent inserts.
+            Note that since TL_WRITE has the same compatibility rules as
+            TL_WRITE_LOW_PRIORITY (their only difference is priority),
+            it is OK to grant new lock without additional checks in such
+            situation.
+        **) The exceptions are situations when:
+            - old lock type is TL_WRITE_CONCURRENT_INSERT and new lock type
+              is TL_WRITE_ALLOW_READ or TL_WRITE_ALLOW_WRITE
+            - old lock type is TL_WRITE_ALLOW_READ and new lock type is
+              TL_WRITE_ALLOW_WRITE
+            - when old lock type is TL_WRITE_DELAYED
+            But these should never happen within MySQL.
         Therefore it is OK to allow acquiring write lock on the table if
         this thread already holds some write lock on it.
 
@@ -716,7 +725,9 @@ thr_lock(THR_LOCK_DATA *data, THR_LOCK_O
         different types of write lock on the same table).
       */
       DBUG_ASSERT(! has_old_lock(lock->write.data, data->owner) ||
-                  (lock_type <= lock->write.data->type &&
+                  ((lock_type <= lock->write.data->type ||
+                    (lock_type == TL_WRITE &&
+                     lock->write.data->type == TL_WRITE_LOW_PRIORITY)) &&
                    ! ((lock_type < TL_WRITE_CONCURRENT_INSERT &&
                        lock->write.data->type == TL_WRITE_CONCURRENT_INSERT) ||
                       (lock_type < TL_WRITE_ALLOW_READ &&


Attachment: [text/bzr-bundle] bzr/jon.hauglid@sun.com-20100108132806-z7ffmatzgbgbf8zm.bundle
Thread
bzr commit into mysql-6.0-codebase branch (jon.hauglid:3747) Bug#48538Jon Olav Hauglid8 Jan