Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.6.18
-
None
Description
The following code in lock_release_on_prepare_try() is redundant after MDEV-33454 implementation:
if (!supremum_bit && rec_granted_exclusive_not_gap) |
continue; |
Because we should not skip granted X-locks and should invoke lock_rec_unlock_unmodified() for X-locks.
The following test case shows the issue:
--source include/have_innodb.inc
|
--source include/count_sessions.inc
|
|
CREATE TABLE t1 (a int, b int, c int,
|
INDEX i1(a),
|
INDEX i2(b))
|
ENGINE=InnoDB;
|
|
INSERT INTO t1 VALUES
|
(1,1,0), (1,2,0),
|
(2,1,0), (2,2,0);
|
|
SET @old_timeout= @@GLOBAL.innodb_lock_wait_timeout;
|
SET GLOBAL innodb_lock_wait_timeout= 1;
|
|
XA START "t1";
|
UPDATE t1 FORCE INDEX (i2) SET c=c+1 WHERE a=1 AND b=1;
|
XA END "t1";
|
XA PREPARE "t1";
|
|
--connect(con1,localhost,root,,)
|
# (pk, 2, 1, 0) record is X-locked but not modified in clustered index with the
|
# above XA transaction, if the bug is not fixed, the following SELECT will be
|
# blocked by the XA transaction if XA PREPARE does not release the unmodified
|
# record.
|
SELECT * FROM t1 FORCE INDEX (i1) WHERE a=2 AND b=1 FOR UPDATE;
|
--disconnect con1
|
|
--connection default
|
XA COMMIT "t1";
|
DROP TABLE t1;
|
|
SET GLOBAL innodb_lock_wait_timeout= @old_timeout;
|
--source include/wait_until_count_sessions.inc
|
Thanks to Elkin for finding the bug.
Attachments
Issue Links
- is blocked by
-
MDEV-34690 lock_rec_unlock_unmodified() causes deadlock
- Closed
- is caused by
-
MDEV-33454 release row locks for non-modified rows at XA PREPARE
- Closed
- relates to
-
MDEV-35227 Executing CHECK TABLE...EXTENDED right after server startup may attempt to access too old history
- Confirmed
-
MDEV-32020 XA transaction replicates incorrectly, must be applied at XA COMMIT, not XA PREPARE
- Open