[MDEV-28422] Page split breaks a gap lock Created: 2022-04-27  Updated: 2022-05-11  Resolved: 2022-04-27

Status: Closed
Project: MariaDB Server
Component/s: Locking, Replication, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
Fix Version/s: 10.3.35, 10.4.25, 10.5.16, 10.6.8, 10.7.4, 10.8.3, 10.9.1

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: consistency

Issue Links:
Relates
relates to MDEV-20605 Awaken transaction can miss inserted ... Closed

 Description   

The INSERT statement in the following test wrongly succeeds when using the default innodb_page_size=16k:

--source include/have_innodb.inc
--source include/have_sequence.inc
--source include/have_debug.inc
 
SET @save_frequency=@@GLOBAL.innodb_purge_rseg_truncate_frequency;
SET GLOBAL innodb_purge_rseg_truncate_frequency=1;
 
CREATE TABLE t1(id INT PRIMARY key, val VARCHAR(16000)) ENGINE=InnoDB;
INSERT INTO t1 (id,val) SELECT 2*seq,'x' FROM seq_0_to_1023;
 
connect(con1,localhost,root,,);
# Prevent purge.
START TRANSACTION WITH CONSISTENT SNAPSHOT;
connection default;
 
DELETE FROM t1 WHERE id=1788;
 
BEGIN;
# This will return no result, but should acquire a gap lock.
SELECT * FROM t1 WHERE id=1788 FOR UPDATE;
 
connection con1;
COMMIT;
source include/wait_all_purged.inc;
connection default;
 
INSERT INTO t1 (id,val) VALUES (1787, REPEAT('x',2000));
 
connection con1;
SET innodb_lock_wait_timeout=0;
--error ER_LOCK_WAIT_TIMEOUT
INSERT INTO t1 (id,val) VALUES (1788, 'x');
SELECT * FROM t1 WHERE id=1788 FOR UPDATE;
disconnect con1;
 
connection default;
COMMIT;
DROP TABLE t1;
SET GLOBAL innodb_purge_rseg_truncate_frequency=@save_frequency;

The above is a simplified version of a test in MySQL 8.0.29. With the fix adapted to MariaDB, the test passes.



 Comments   
Comment by Matthias Leich [ 2022-04-27 ]

origin/bb-10.6-MDEV-28422 a291a300400ece95d3e0a64f687d6515a5104dde 2022-04-27T13:16:07+03:00
behaved well in RQG testing.

Generated at Thu Feb 08 10:00:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.