Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
N/A
-
Not for Release Notes
-
Q3/2025 Maintenance
Description
--source include/have_log_bin.inc
|
--source include/have_innodb.inc
|
|
# Search pattern(s): (?^s:thd->lex->xa_opt == XA_ONE_PHASE)
|
|
CREATE TABLE t1 (a INT) ENGINE=InnoDB; |
INSERT INTO t1 VALUES (1),(2) ; |
CREATE TABLE t2 (b INT) ENGINE=InnoDB; |
CREATE TABLE t3 (c INT) ENGINE=InnoDB; |
INSERT INTO t3 VALUES (1),(2); |
|
--connect (con1,localhost,root,,)
|
XA BEGIN 'x1'; |
--connection default
|
XA BEGIN 'x2'; |
DELETE FROM t1; |
--connection con1
|
DELETE FROM t3 WHERE c = 2; |
--connection default
|
--send
|
DELETE FROM t3; |
--connection con1
|
--error ER_LOCK_DEADLOCK
|
DELETE FROM t1; |
INSERT INTO t2 VALUES (1); |
|
# Cleanup
|
|
--error ER_XA_RBDEADLOCK
|
XA END 'x1'; |
--disconnect con1
|
--connection default
|
--reap
|
XA END 'x2'; |
XA ROLLBACK 'x2'; |
DROP TABLE t1, t2, t3; |
10.11 c8cf8d352899a264203b4f49085b013b29a4a59f |
mariadbd: /data/bld/10.11-asan-ubsan/sql/handler.cc:1972: int ha_commit_trans(THD*, bool): Assertion `!thd->transaction->xid_state.is_explicit_XA() || thd->lex->xa_opt == XA_ONE_PHASE' failed.
|
250630 12:06:02 [ERROR] /share8t/bld/10.11-asan-ubsan/sql/mariadbd got signal 6 ;
|
|
#9 0x00007efccbc45395 in __assert_fail_base (fmt=0x7efccbdb9a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x56262850d700 "!thd->transaction->xid_state.is_explicit_XA() || thd->lex->xa_opt == XA_ONE_PHASE", file=file@entry=0x562628502160 "/data/bld/10.11-asan-ubsan/sql/handler.cc", line=line@entry=1972, function=function@entry=0x56262850d380 "int ha_commit_trans(THD*, bool)") at ./assert/assert.c:92
|
#10 0x00007efccbc53eb2 in __GI___assert_fail (assertion=0x56262850d700 "!thd->transaction->xid_state.is_explicit_XA() || thd->lex->xa_opt == XA_ONE_PHASE", file=0x562628502160 "/data/bld/10.11-asan-ubsan/sql/handler.cc", line=1972, function=0x56262850d380 "int ha_commit_trans(THD*, bool)") at ./assert/assert.c:101
|
#11 0x0000562625b627b1 in ha_commit_trans (thd=thd@entry=0x62c000240218, all=all@entry=false) at /data/bld/10.11-asan-ubsan/sql/handler.cc:1972
|
#12 0x0000562625118756 in trans_commit_stmt (thd=thd@entry=0x62c000240218) at /data/bld/10.11-asan-ubsan/sql/transaction.cc:501
|
#13 0x000056262488c878 in mysql_execute_command (thd=thd@entry=0x62c000240218, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:6226
|
#14 0x000056262488fc01 in mysql_parse (thd=thd@entry=0x62c000240218, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7efcb92b9ab0) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:8180
|
#15 0x0000562624898ed5 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x62c000240218, packet=packet@entry=0x6290002fd219 "INSERT INTO t2 VALUES (1)", packet_length=packet_length@entry=25, blocking=blocking@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:1906
|
#16 0x00005626248a5b11 in do_command (thd=thd@entry=0x62c000240218, blocking=blocking@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:1419
|
#17 0x0000562625097c64 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x608000021638, put_in_cache=put_in_cache@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_connect.cc:1386
|
#18 0x0000562625098dc1 in handle_one_connection (arg=0x608000021638) at /data/bld/10.11-asan-ubsan/sql/sql_connect.cc:1298
|
#19 0x00005626269f8a69 in pfs_spawn_thread (arg=0x617000008c98) at /data/bld/10.11-asan-ubsan/storage/perfschema/pfs.cc:2201
|
#20 0x00007efccbca81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#21 0x00007efccbd2885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
No obvious immediate problem on a non-debug build, but maybe there are some anomalies with binary logging, for example, I didn't investigate.
The failure started happening after this commit in 10.11:
commit 0680e31737a79959a69f3c2cb90458834359ece3 (origin/10.11-MDEV-37057)
|
Commit: mariadb-DebarunBanerjee
|
CommitDate: Tue Jun 24 13:34:27 2025 +0530
|
|
MDEV-36959 Deadlock does not rollback transaction fully
|
It hasn't yet been merged up to higher versions, and it would be good to have it fixed before it happens.
Attachments
Issue Links
- is caused by
-
MDEV-36959 Deadlock does not rollback transaction fully
-
- Closed
-
- relates to
-
MDEV-37141 DML committed within XA transaction block after deadlock error and implicit rollback
-
- Closed
-