mirror of
https://github.com/MariaDB/server.git
synced 2025-07-04 18:38:14 +02:00
0680e31737
A deadlock forces the on going transaction to rollback implicitly. Within a transaction block, started with START TRANSACTION / BEGIN, implicit rollback doesn't reset OPTION_BEGIN flag. It results in a new implicit transaction to start when the next statement is executed. This behaviour is unexpected and should be fixed. However, we should note that there is no issue with rollback. We fix the issue to keep the behaviour of implicit rollback (deadlock) similar to explicit COMMIT and ROLLBACK i.e. the next statement after deadlock error is not going to start a transaction block implicitly unless autocommit is set to zero.
43 lines
1,018 B
Text
43 lines
1,018 B
Text
#
|
|
# MDEV-36959 Deadlock does not rollback transaction fully
|
|
#
|
|
CREATE TABLE t1(col1 INT PRIMARY KEY, col2 INT) ENGINE=InnoDB;
|
|
INSERT INTO t1 VALUES (1, 1), (2, 2);
|
|
SELECT * FROM t1;
|
|
col1 col2
|
|
1 1
|
|
2 2
|
|
connect con1,localhost,root,,;
|
|
START TRANSACTION;
|
|
# Trx-1: Lock 1st record
|
|
UPDATE t1 SET col2=10 where col1=1;
|
|
connection default;
|
|
START TRANSACTION;
|
|
# Trx-2: Lock 2nd record
|
|
UPDATE t1 SET col2=100 where col1=2;
|
|
connection con1;
|
|
# Trx-1: Try locking 1st record : Wait
|
|
UPDATE t1 SET col2=10 where col1=2;
|
|
connection default;
|
|
# Wait for Trx-1 to get into lock wait stage
|
|
# Trx-2: Try locking 2nd record : Deadlock
|
|
UPDATE t1 SET col2=100 where col1=1;
|
|
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
|
|
connection con1;
|
|
ROLLBACK;
|
|
connection default;
|
|
SELECT @@in_transaction;
|
|
@@in_transaction
|
|
0
|
|
UPDATE t1 SET col2=10 where col1=1;
|
|
UPDATE t1 SET col2=100 where col1=2;
|
|
SELECT @@in_transaction;
|
|
@@in_transaction
|
|
0
|
|
ROLLBACK;
|
|
disconnect con1;
|
|
SELECT * FROM t1;
|
|
col1 col2
|
|
1 10
|
|
2 100
|
|
DROP TABLE t1;
|