Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5(EOL), 10.6(EOL), 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
-
Can result in hang or crash
Description
When an user prepared XA does not update data it expectedly does not survive
the server restart.
However in case of crash it gets recovered. Here is a test:
--source include/have_binlog_format_mixed.inc
|
--source include/have_innodb.inc
|
|
|
# MDEV-TODO unneccessary recover of read-only transaction
|
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
|
INSERT INTO t1 VALUES (1);
|
|
|
call mtr.add_suppression("Found 1 prepared XA transactions");
|
|
|
XA START '1';
|
--error ER_DUP_ENTRY
|
INSERT INTO t1 VALUES (2),(1);
|
--echo Despite '1' has done no work ...
|
SELECT * FROM t1 WHERE a = 2;
|
XA END '1';
|
XA PREPARE '1';
|
XA RECOVER;
|
|
|
--echo server crash
|
--let $shutdown_timeout=0
|
--source include/restart_mysqld.inc
|
|
|
--connection default
|
--enable_reconnect
|
--echo ... it is recovered:
|
XA RECOVER;
|
|
|
# Cleanup
|
XA ROLLBACK '1';
|
DROP TABLE t1;
|
The recoverable behavior is more than unnecessary as it's harmful for replication because of
inconsistent prepared status. There are reasons to claim that the "read-only" prepared user XA should not be recovered.
Attachments
Issue Links
- relates to
-
MDEV-742 LP:803649 - Xa recovery failed on client disconnection
-
- Closed
-
-
MDEV-25616 Binlog event for XA COMMIT is generated without matching XA START, replication aborts
-
- Closed
-