Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.5.37
-
Fix Version/s: 5.5.39
-
Component/s: None
-
Labels:None
Description
mariadb-5.5/storage/xtradb/row/row0sel.c line 4137
if (set_also_gap_locks
&& !(srv_locks_unsafe_for_binlog
|| trx->isolation_level <= TRX_ISO_READ_COMMITTED)
&& prebuilt->select_lock_type != LOCK_NONE) {
/* Try to place a lock on the index record */
/* If innodb_locks_unsafe_for_binlog option is used
or this session is using a READ COMMITTED isolation
level we do not lock gaps. Supremum record is really
a gap and therefore we do not set locks there. */
I was getting really confused about the comment and its relation to the code and I've come to the conclusion that the comment should say "this session is not using a REPEATABLE READ" and perhaps the condition could be isolation_level < TRX_ISO_REPEATABLE_READ to match.
Of course I've looked at this too long and just may be wrong.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Idea with that code is that if innodb_locks_unsafe_for_binlog option is used or this session is using
READ_COMMITTED or lower isolation level we do not lock gaps. Supremum record is really a
gap and therefore we do not set locks there.
revno: 4223
committer: Jan Lindström <jplindst@mariadb.org>
branch nick: 5.5
timestamp: Fri 2014-07-04 08:42:59 +0300
message:
MDEV-6191: row_search_for_mysql comment and code consistency about isolation level
and gap locks
The comment looks okay to me... I mean, for total accuracy, it could have said "using a READ (UN)COMMITTED isolation level", but this "UN" is kind of obvious.
Although, I've looked at it too briefly, will assign to Jan for an expert look.