mirror of
https://github.com/MariaDB/server.git
synced 2025-02-09 23:24:11 +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>
24 lines
461 B
Text
24 lines
461 B
Text
connection node_2;
|
|
connection node_1;
|
|
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;
|
|
f1
|
|
SAVEPOINT s1;
|
|
ERROR 42000: The storage engine for the table doesn't support SAVEPOINT
|
|
INSERT INTO t1 VALUES (2);
|
|
COMMIT;
|
|
connection node_1;
|
|
SELECT * FROM t1;
|
|
f1
|
|
1
|
|
2
|
|
connection node_2;
|
|
SELECT * FROM t1;
|
|
f1
|
|
1
|
|
2
|
|
connection node_1;
|
|
DROP TABLE t1,t2;
|