bzr commit into mysql-6.0-bugteam branch (kristofer.pettersson:3109) Bug#43568

[Kristofer Pettersson]

#At file:///home/thek/Development/cpp/mysqlbzr/mysql-6.0-bugteam/ based on revid:kristofer.pettersson@stripped

 3109 Kristofer Pettersson	2009-03-12
      Bug#43568 set_handler_table_locks uses parser tokens instead of correct lock_options
      
      set_handler_table_locks uses parser tokens instead of correct lock options to
      determine the correct lock to set.
      
      After open_tables, the correct lock option is stored in TABLE::reginfo.lock_type.
      Failing to use the correct lock option might create issues with binlog and replication.

    modified:
      sql/lock.cc
=== modified file 'sql/lock.cc'
--- a/sql/lock.cc	2009-02-16 21:18:45 +0000
+++ b/sql/lock.cc	2009-03-12 11:43:21 +0000
@@ -1585,18 +1585,11 @@ int set_handler_table_locks(THD *thd, TA
     if (tlist->placeholder())
       continue;
 
-    DBUG_ASSERT((tlist->lock_type == TL_READ) ||
-                (tlist->lock_type == TL_READ_NO_INSERT) ||
-                (tlist->lock_type == TL_WRITE_DEFAULT) ||
-                (tlist->lock_type == TL_WRITE) ||
-                (tlist->lock_type == TL_WRITE_CONCURRENT_INSERT) ||
-                (tlist->lock_type == TL_WRITE_LOW_PRIORITY));
-
     /*
       Every tlist object has a proper lock_type set. Even if it came in
       the list as a base table from a view only.
     */
-    lock_type= ((tlist->lock_type <= TL_READ_NO_INSERT) ?
+    lock_type= ((tlist->table->reginfo.lock_type <= TL_READ_NO_INSERT) ?
                 HA_LOCK_IN_SHARE_MODE : HA_LOCK_IN_EXCLUSIVE_MODE);
 
     if (transactional)


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