Bug #43568 set_handler_table_locks uses parser tokens instead of correct lock_options
Submitted: 11 Mar 2009 16:33 Modified: 19 Mar 2009 3:32
Reporter: Kristofer Pettersson Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:6.0-bzr OS:Any
Assigned to: Kristofer Pettersson CPU Architecture:Any

[11 Mar 2009 16:33] Kristofer Pettersson 
Description:
During the parser phase a syntactical element lock_option is used to indicate
which lock the current query should be trying to use.

After the parser phase this variable is translated to the table->reginfo->lock_option variable based on semantic analysis.

set_handler_type_for_tables should be looking at this analysis and not on the raw parser data.

How to repeat:
Cases assert failure in main.locktrans_innodb.

Suggested fix:
Remove the assert as it is bogus.
Change the function to operate on the lock_option value in the reginfo structure.
[12 Mar 2009 10:45] Kristofer Pettersson 
Tests like ndb.ndb_dbug_lock fail if you assert that reginfo.lock_option should be free of parser bound states like TL_WRITE_DEFAULT. However it seems possible to assert that TL_READ_DEFAULT is parser bound and never passed to reginfo.lock_option.

TL_WRITE_DEFAULT was introduced by bug patch #26162 and TL_READ_DEFAULT was introduces by bug patch #34306 to mimic the solution in #26162.

Issues with the dependencies on the different states where commented on in WL3726 patches.
[12 Mar 2009 11:29] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/69028

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.
[12 Mar 2009 20:33] Kristofer Pettersson 
Clarification: in the description above I've written lock_option although I'd should have written lock_type which is the variable name used to represent a lock option.
[13 Mar 2009 11:24] Ingo Strüwing 
Approved. Please see email for comments.
[13 Mar 2009 14:23] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/69157

3111 Kristofer Pettersson	2009-03-13
      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.
     @ include/thr_lock.h
        * Added comment.
     @ sql/lock.cc
        * set transactional lock type based on TABLE::reginfo.locktype
          instead of TABLE_LIST::lock_type.
[18 Mar 2009 13:18] Bugs System 
Pushed into 6.0.11-alpha (revid:joro@sun.com-20090318122208-1b5kvg6zeb4hxwp9) (version source revid:joro@sun.com-20090317133112-41qn6aly7arljtlq) (merge vers: 6.0.11-alpha) (pib:6)
[19 Mar 2009 3:32] Paul DuBois 
Noted in 6.0.11 changelog.

Incorrect use of parser information could lead to acquisition of
incorrect lock types.
[17 Dec 2009 11:00] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/94708

2932 Ingo Struewing	2009-12-17
      WL#3561 - transactional LOCK TABLE
      Backport.
      Backported revision revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
        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.
      Most changes have been included in the first patch already.
     @ include/thr_lock.h
        WL#3561 - transactional LOCK TABLE
        Backport.
          Bug#43568 set_handler_table_locks uses parser tokens instead 
                    of correct lock_options
          * Added comment.
[18 Dec 2009 16:49] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/94980

2940 Ingo Struewing	2009-12-18
      WL#3561 - transactional LOCK TABLE
      Backport.
      Backported revision revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
        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.
            
      This leaves the tree with failing *locktrans* test cases.
      They should be fixed with backports of follow-up revisions.
     @ include/thr_lock.h
        WL#3561 - transactional LOCK TABLE
        Backport.
        Backported revision revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
          * Added comment.
     @ sql/lock.cc
        WL#3561 - transactional LOCK TABLE
        Backport.
        Backported revision revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
          * set transactional lock type based on TABLE::reginfo.locktype
            instead of TABLE_LIST::lock_type.
[8 Apr 2010 17:28] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/105254

3129 Ingo Struewing	2010-04-08
      Backport of revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
        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.
      
      This leaves main.locktrans_innodb failing due to a misinterpretation
      of placeholder(). To be fixed by backport of
      revid:sp1r-istruewing@synthia.local-20070413065240-12601
     @ include/thr_lock.h
        Backport of revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
            * Added comment.
     @ sql/lock.cc
        Backport of revid:kristofer.pettersson@sun.com-20090313182810-dvc3hwuitror1wr1
            * set transactional lock type based on TABLE::reginfo.locktype
              instead of TABLE_LIST::lock_type.