Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5.14, 10.6.6, 10.7.3
-
OS: Ubuntu-20.04 LTS
Description
Isolation Level: Read Committed & Read Uncommitted
One transaction modifies a row, the other transaction concurrently deletes that row and is blocked. After blocking is released, the second transaction DELETE fails.
/* init */ DROP TABLE IF EXISTS t; |
/* init */ CREATE TABLE t(c1 INT PRIMARY KEY, c2 INT); |
/* init */ INSERT INTO t(c1) VALUES (8); |
|
/* t1 */ BEGIN; |
/* t2 */ BEGIN; |
/* t1 */ UPDATE t SET c1 = 5, c2 = 5; |
/* t2 */ DELETE FROM t; -- blocked |
/* t1 */ UPDATE t SET c1 = 3; |
/* t1 */ COMMIT; -- t2 unblocked |
/* t2 */ SELECT * FROM t FOR UPDATE; -- [(3, 5)] |
/* t2 */ ROLLBACK; |
Attachments
Issue Links
- is caused by
-
MDEV-27025 insert-intention lock conflicts with waiting ORDINARY lock
-
- Closed
-
- relates to
-
MDEV-29433 innodb.lock_delete_updated is unstable
-
- Closed
-
-
MDEV-34877 Port "Bug #11745929 Change lock priority so that the transaction holding S-lock gets X-lock first" fix from MySQL to MariaDB
-
- Closed
-
-
MDEV-24813 Locking full table scan fails to use table-level locking
-
- In Review
-
-
SAMU-292 Failed to load