Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
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