mariadb/mysql-test/suite/innodb/t/trx_deadlock.test
mariadb-DebarunBanerjee 0680e31737 MDEV-36959 Deadlock does not rollback transaction fully
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.
2025-06-24 13:34:27 +05:30

52 lines
1.2 KiB
Text

--echo #
--echo # MDEV-36959 Deadlock does not rollback transaction fully
--echo #
--source include/have_innodb.inc
--source include/count_sessions.inc
CREATE TABLE t1(col1 INT PRIMARY KEY, col2 INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1, 1), (2, 2);
SELECT * FROM t1;
--connect (con1,localhost,root,,)
START TRANSACTION;
--echo # Trx-1: Lock 1st record
UPDATE t1 SET col2=10 where col1=1;
--connection default
START TRANSACTION;
--echo # Trx-2: Lock 2nd record
UPDATE t1 SET col2=100 where col1=2;
--connection con1
--echo # Trx-1: Try locking 1st record : Wait
--send UPDATE t1 SET col2=10 where col1=2
--connection default
--echo # Wait for Trx-1 to get into lock wait stage
let $wait_condition=
SELECT COUNT(*) >= 2 FROM INFORMATION_SCHEMA.INNODB_LOCKS
WHERE lock_table like "%t1%";
--source include/wait_condition.inc
--echo # Trx-2: Try locking 2nd record : Deadlock
--error ER_LOCK_DEADLOCK
UPDATE t1 SET col2=100 where col1=1;
--connection con1
--reap
ROLLBACK;
--connection default
SELECT @@in_transaction;
UPDATE t1 SET col2=10 where col1=1;
UPDATE t1 SET col2=100 where col1=2;
SELECT @@in_transaction;
ROLLBACK;
--disconnect con1
SELECT * FROM t1;
DROP TABLE t1;
--source include/wait_until_count_sessions.inc