Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.3.9, 10.4(EOL), 10.5, 10.6
Description
After the following commit:
commit 1748a31ae8d69e4939336f644f884e9de3039e7f
|
Author: Marko Mäkelä <marko.makela@mariadb.com>
|
Date: Tue Jul 3 15:10:06 2018 +0300
|
MDEV-16675 Unnecessary explicit lock acquisition during UPDATE or DELETE
|
|
lock_rec_convert_impl_to_expl() does not create explicit lock if the caller holds implicit lock.
Suppose we have the following call stack:
▾ lock_rec_convert_impl_to_expl
|
▾ lock_clust_rec_read_check_and_lock
|
▾ sel_set_rec_lock
|
▸ row_search_mvcc
|
If lock type is LOCK_GAP or LOCK_ORDINARY, and the transaction holds implicit lock for the record, then explicit gap-lock will not be set for the record, as lock_rec_convert_impl_to_expl() returns true and lock_rec_convert_impl_to_expl() bypasses lock_rec_lock() call.
The following test shows the issue:
--source include/have_innodb.inc
|
--source include/count_sessions.inc
|
CREATE TABLE t(a INT UNSIGNED PRIMARY KEY) ENGINE=InnoDB;
|
INSERT INTO t VALUES (10), (30);
|
--connect (con1,localhost,root,,)
|
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
BEGIN;
|
INSERT INTO t VALUES (20);
|
SELECT * FROM t WHERE a BETWEEN 10 AND 30;
|
--connection default
|
SET session innodb_lock_wait_timeout=1;
|
--error ER_LOCK_WAIT_TIMEOUT
|
INSERT INTO t VALUES (15);
|
--disconnect con1
|
DROP TABLE t;
|
--source include/wait_until_count_sessions.inc
|
Attachments
Issue Links
- blocks
-
MDEV-20605 Awaken transaction can miss inserted by other transaction records due to wrong persistent cursor restoration
- Closed
- is caused by
-
MDEV-16675 Unnecessary explicit lock acquisition during UPDATE or DELETE
- Closed