database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

ha_innodb.cc:

Browse Source 
Fix potential bug: if MySQL calls store_lock with the TL_IGNORE argument in the middle of query processing, then InnoDB select_lock_type could be reset to LOCK_NONE in a wrong place


sql/ha_innodb.cc:
  Fix potential bug: if MySQL calls store_lock with the TL_IGNORE argument in the middle of query processing, then InnoDB select_lock_type could be reset to LOCK_NONE in a wrong place
This commit is contained in:
unknown
2003-02-05 01:24:59 +02:00
parent dfbd628cd7
commit ed3b80e1b2
1 changed files with 11 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
sql/ha_innodb.cc
View File

@ -4128,7 +4128,10 @@ static void free_share(INNOBASE_SHARE *share)
}
/*********************************************************************
Stores a MySQL lock into a 'lock' field in a handle. */
Converts a MySQL table lock stored in the 'lock' field of the handle to
a proper type before storing the lock. MySQL also calls this when it
releases a lock. */
THR_LOCK_DATA**
ha_innobase::store_lock(
@ -4154,8 +4157,13 @@ ha_innobase::store_lock(
binlog) requires the use of a locking read */
prebuilt->select_lock_type = LOCK_S;
} else {
/* We set possible LOCK_X value in external_lock, not yet
} else if (lock_type != TL_IGNORE) {
/* In ha_berkeley.cc there is a comment that MySQL
may in exceptional cases call this with TL_IGNORE also
when it is NOT going to release the lock. */
/* We set possible LOCK_X value in external_lock, not yet
here even if this would be SELECT ... FOR UPDATE */
prebuilt->select_lock_type = LOCK_NONE;