mirror of
https://github.com/MariaDB/server.git
synced 2025-02-04 21:02:17 +01:00
362c0950e8
Attempting to set a SAVEPOINT when one of the involved storage engines does not support savepoints, raises an error, and results in statement rollback. If Galera is enabled with binlog emulation, the above scenario was not handled correctly, and resulted in cluster wide inconsistency. The problem was in wsrep_register_binlog_handler(), which is called towards the beginning of SAVEPOINT execution. This function is supposed to mark the beginning of statement position in trx cache through `set_prev_position()`. However, it did so only on condition that `get_prev_position()` returns `MY_OFF_T_UNDEF`. This before statement position is typically reset to undefined at the end of statement in `binlog_commit()` / `binlog_rollback()`. However that's not the case with Galera and binlog emulation, for which binlog commit / rollback hooks are not called due to the optimization that avoids internal 2PC (MDEV-16509). Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
28 lines
591 B
Text
28 lines
591 B
Text
#
|
|
# MDEV-32549: Cluster is inconsitent after savepoint
|
|
# statement is rolled back
|
|
#
|
|
--source include/galera_cluster.inc
|
|
|
|
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) engine=innodb;
|
|
CREATE TABLE t2 (f1 INTEGER PRIMARY KEY) engine=aria;
|
|
|
|
START TRANSACTION;
|
|
INSERT INTO t1 VALUES (1);
|
|
SELECT * FROM t2;
|
|
--error ER_CHECK_NOT_IMPLEMENTED
|
|
SAVEPOINT s1;
|
|
INSERT INTO t1 VALUES (2);
|
|
COMMIT;
|
|
|
|
--connection node_1
|
|
SELECT * FROM t1;
|
|
|
|
# If bug is present: only the second INSERT
|
|
# is replicated, causing an inconsistent
|
|
# cluster.
|
|
--connection node_2
|
|
SELECT * FROM t1;
|
|
|
|
--connection node_1
|
|
DROP TABLE t1,t2;
|