Bug #43568 set_handler_table_locks uses parser tokens instead of correct lock_options

• Submitted: 11 Mar 17:33
• Modified: 19 Mar 4:32
• Reporter: Kristofer Pettersson
• Status: Closed
• Category: Server
• Severity: S3 (Non-critical)
• Version: 6.0-bzr
• OS: Any
• Assigned to: Kristofer Pettersson

[11 Mar 17: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 11: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 12: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 21: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 12:24] Ingo Strüwing

Approved. Please see email for comments.

[13 Mar 15: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 14:18] Bugs System

Pushed into 6.0.11-alpha (revid:[e-mail]-20090318122208-1b5kvg6zeb4hxwp9) (version
source revid:[e-mail]-20090317133112-41qn6aly7arljtlq) (merge vers: 6.0.11-alpha)
(pib:6)

[19 Mar 4:32] Paul DuBois

Noted in 6.0.11 changelog.

Incorrect use of parser information could lead to acquisition of
incorrect lock types.