mirror of
https://github.com/MariaDB/server.git
synced 2025-01-22 14:54:20 +01:00
47edc4cade
DML flow and SAVEPOINT The problem was that replication could break if a transaction involving both transactional and non-transactional tables was rolled back to a savepoint. It broke if a concurrent connection tried to drop a transactional table which was locked after the savepoint was set. This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the lock on the table was dropped by the transaction. When the slave later tried to apply the binlog, it would fail as the table would already have been dropped. The reason for the problem is that transactions involving both transactional and non-transactional tables are written fully to the binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT. This allowed a second connection to drop a table only used between SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog to refer to a non-existing table when it was written during ROLLBACK TO SAVEPOINT. This patch fixes the problem by not releasing metadata locks when ROLLBACK TO SAVEPOINT is executed if binlogging is enabled. |
||
|---|---|---|
| .. | ||
| binlog | ||
| bugs | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| ibmdb2i | ||
| innodb | ||
| jp | ||
| large_tests | ||
| manual | ||
| ndb | ||
| ndb_team | ||
| parts | ||
| perfschema | ||
| perfschema_stress | ||
| rpl | ||
| rpl_ndb | ||
| stress | ||
| sys_vars | ||