mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-31 11:01:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/innodb/r/xa_recovery_debug.result

27 lines
623 B
Text
Raw Normal View History

MDEV-13626: Import and adapt innodb.xa_recovery_debug Adapt the test that was added in mysql/mysql-server@6b65d9032cbb6c1016cb09d056df6885e3d25dc6 but omitted in commit 2e814d4702d71a04388386a9f591d14a35980bfe. Instead of triggering a log checkpoint, we will only trigger a redo log flush before killing the server. Note: the mtr.commit() call in trx_rollback_for_mysql() will not actually make the undo log header page state change durable. A call to log_write_up_to(mtr.commit_lsn(), true) would do that. It is unclear what the originally reported bug scenario was. As long as innobase_rollback_by_xid() will not return without ensuring that the redo log has been durably written, we should be safe.
2020-03-31 15:10:54 +03:00
#
# Bug#20872655 XA ROLLBACK IS NOT CRASH-SAFE
#
CREATE TABLE t(a INT PRIMARY KEY, b INT UNIQUE) ENGINE=INNODB;
INSERT INTO t SET a=0;
connect con1,localhost,root;
XA START 'zombie';
INSERT INTO t SET a=1;
UPDATE t SET b=1 WHERE a=1;
SELECT COUNT(*) FROM t;
COUNT(*)
2
XA END 'zombie';
XA PREPARE 'zombie';
MDEV-13626: Improve innodb.xa_recovery_debug Improve the test that was imported and adapted for MariaDB in commit fb217449dce9f6996563d5aa257be01c12df4a11. row_undo_step(): Move the DEBUG_SYNC point from trx_rollback_for_mysql(). This DEBUG_SYNC point is executed after rolling back one row. trx_rollback_for_mysql(): Clarify the comments that describe the scenario, and remove the DEBUG_SYNC point. If the statement "if (trx->has_logged_persistent())" and its body are removed from trx_rollback_for_mysql(), then the test innodb.xa_recovery_debug will fail because the transaction would still exist in the XA PREPARE state. If we allow the XA COMMIT statement to succeed in the test, we would observe an incorrect state of the XA transaction where the table would contain row (1,NULL). Depending on whether the XA transaction was committed, the table should either be empty or contain the record (1,1). The intermediate state of (1,NULL) should never be observed after completed recovery.
2020-04-01 09:13:01 +03:00
SET DEBUG_SYNC='trx_after_rollback_row SIGNAL s1 WAIT_FOR s2';
MDEV-13626: Import and adapt innodb.xa_recovery_debug Adapt the test that was added in mysql/mysql-server@6b65d9032cbb6c1016cb09d056df6885e3d25dc6 but omitted in commit 2e814d4702d71a04388386a9f591d14a35980bfe. Instead of triggering a log checkpoint, we will only trigger a redo log flush before killing the server. Note: the mtr.commit() call in trx_rollback_for_mysql() will not actually make the undo log header page state change durable. A call to log_write_up_to(mtr.commit_lsn(), true) would do that. It is unclear what the originally reported bug scenario was. As long as innobase_rollback_by_xid() will not return without ensuring that the redo log has been durably written, we should be safe.
2020-03-31 15:10:54 +03:00
XA ROLLBACK 'zombie';
connection default;
SET DEBUG_SYNC='now WAIT_FOR s1';
SET GLOBAL innodb_flush_log_at_trx_commit=1;
DELETE FROM t LIMIT 1;
disconnect con1;
XA COMMIT 'zombie';
ERROR XAE04: XAER_NOTA: Unknown XID
MDEV-13626: Improve innodb.xa_recovery_debug Improve the test that was imported and adapted for MariaDB in commit fb217449dce9f6996563d5aa257be01c12df4a11. row_undo_step(): Move the DEBUG_SYNC point from trx_rollback_for_mysql(). This DEBUG_SYNC point is executed after rolling back one row. trx_rollback_for_mysql(): Clarify the comments that describe the scenario, and remove the DEBUG_SYNC point. If the statement "if (trx->has_logged_persistent())" and its body are removed from trx_rollback_for_mysql(), then the test innodb.xa_recovery_debug will fail because the transaction would still exist in the XA PREPARE state. If we allow the XA COMMIT statement to succeed in the test, we would observe an incorrect state of the XA transaction where the table would contain row (1,NULL). Depending on whether the XA transaction was committed, the table should either be empty or contain the record (1,1). The intermediate state of (1,NULL) should never be observed after completed recovery.
2020-04-01 09:13:01 +03:00
SELECT * FROM t;
a b
MDEV-13626: Import and adapt innodb.xa_recovery_debug Adapt the test that was added in mysql/mysql-server@6b65d9032cbb6c1016cb09d056df6885e3d25dc6 but omitted in commit 2e814d4702d71a04388386a9f591d14a35980bfe. Instead of triggering a log checkpoint, we will only trigger a redo log flush before killing the server. Note: the mtr.commit() call in trx_rollback_for_mysql() will not actually make the undo log header page state change durable. A call to log_write_up_to(mtr.commit_lsn(), true) would do that. It is unclear what the originally reported bug scenario was. As long as innobase_rollback_by_xid() will not return without ensuring that the redo log has been durably written, we should be safe.
2020-03-31 15:10:54 +03:00
DROP TABLE t;
Reference in a new issue Copy permalink