Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Won't Fix
-
10.6.5, 10.7.1, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL)
-
OS: Ubuntu-20.04 LTS
Description
Under Repeatable Read isolation level, if two transactions concurrently execute and deadlock happend, the transaction that reported deadlock still executes remaining statements by transaction.
/* init */ CREATE TABLE t(c1 INT PRIMARY KEY, c2 INT UNIQUE); |
/* init */ INSERT INTO t(c1) VALUES (8); |
/* t1 */ BEGIN; |
/* t1 */ UPDATE t SET c1=5, c2=7 WHERE -19; |
/* t2 */ BEGIN; |
/* t2 */ DELETE FROM t WHERE -15; -- blocked |
/* t1 */ UPDATE t SET c1=3 WHERE 0.5; |
/* t2 */ DELETE FROM t WHERE -15; -- deadlock |
/* t2 */ ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
/* t1 */ COMMIT; |
/* t2 */ INSERT IGNORE INTO t(c1) VALUES (2); |
/* t2 */ SELECT * FROM t FOR UPDATE; -- [(2, NULL), (3, 7)] |
/* t2 */ ROLLBACK; |
/* t2 */ SELECT * FROM t FOR UPDATE; -- [(3, 7)] |
Due to the application of autocommit, the ROLLBACK statement should have no effect after deadlock in t2. The last select should return [(2, NULL), (3, 7)].
Attachments
Issue Links
- relates to
-
MDEV-27025 insert-intention lock conflicts with waiting ORDINARY lock
- Closed