Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6
Description
A statement such as LOAD INDEX INTO may cause a prepared XA to rollback.
For instance, consider the following case:
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) Engine=Innodb;
|
SHOW CREATE TABLE t1;
|
Table Create Table
|
t1 CREATE TABLE `t1` (
|
`f1` int(11) NOT NULL,
|
PRIMARY KEY (`f1`)
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1
|
XA START 'a';
|
INSERT INTO t1 VALUES (1);
|
XA END 'a';
|
XA PREPARE 'a';
|
LOAD INDEX INTO cache t1 KEY(PRIMARY);
|
Table Op Msg_type Msg_text
|
test.t1 preload_keys Error XAER_RMFAIL: The command cannot be executed when global transaction is in the PREPARED state
|
test.t1 preload_keys error Corrupt
|
XA COMMIT 'a';
|
SELECT COUNT(*) FROM t1;
|
COUNT(*)
|
0
|
After XA PREPARE the user attempts to LOAD INDEX, internally, it causes a trans_rollback_implicit(), which will roll back the underlying XA transaction. After XA COMMIT the transaction left no side effects.
I would expect LOAD INDEX to not rollback the underlying XA transaction, and fail immediately with "XAER_RMFAIL: The command cannot be executed when global transaction is in PREPARED state".
Attachments
Issue Links
- is duplicated by
-
MDEV-25516 Assertion `m_thd == _current_thd()' failed in virtual int Wsrep_client_service::bf_rollback()
- Closed
- relates to
-
MDEV-21516 Assertion `lock_rec_find_set_bit(lock) == ((ulint)(-1))' failed in lock_rec_free_all_from_discard_page_low on ROLLBACK of SPATIAL INDEX
- Confirmed
-
MDEV-30550 Assertion `state() == s_executing || state() == s_prepared || state() == s_committed || state() == s_aborted || state() == s_must_replay' failed
- Confirmed