1
0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00

Bug#42643: InnoDB does not support replication of TRUNCATE TABLE

The problem was that TRUNCATE TABLE didn't take a exclusive
lock on a table if it resorted to truncating via delete of
all rows in the table. Specifically for InnoDB tables, this
could break proper isolation as InnoDB ends up aborting some
granted locks when truncating a table.

The solution is to take a exclusive metadata lock before
TRUNCATE TABLE can proceed. This guarantees that no other
transaction is using the table.

Incompatible change: Truncate via delete no longer fails
if sql_safe_updates is activated (this was a undocumented
side effect).
This commit is contained in:
Davi Arnaut
2010-05-25 17:01:38 -03:00
parent a3c080be7a
commit 3c279d9a5a
38 changed files with 1471 additions and 441 deletions

View File

@@ -25,3 +25,44 @@ TRUNCATE TABLE t2;
source include/show_binlog_events.inc;
DROP TABLE t1,t2;
--echo #
--echo # Bug#42643: InnoDB does not support replication of TRUNCATE TABLE
--echo #
eval CREATE TABLE t1 (a INT) ENGINE=$engine;
eval CREATE TABLE t2 (a INT) ENGINE=$engine;
INSERT INTO t1 VALUES (1),(2);
let $binlog_start = query_get_value("SHOW MASTER STATUS", Position, 1);
if (`select length('$before_truncate') > 0`) {
eval $before_truncate;
}
--echo # Connection: default
BEGIN;
INSERT INTO t2 SELECT * FROM t1;
connect (truncate,localhost,root,,);
--echo # Connection: truncate
send TRUNCATE TABLE t1;
connection default;
--echo # Connection: default
INSERT INTO t2 SELECT * FROM t1;
SELECT COUNT(*) FROM t2;
COMMIT;
connection truncate;
--echo # Connection: truncate
--echo # Reaping TRUNCATE TABLE
--reap
SELECT COUNT(*) FROM t1;
SELECT COUNT(*) FROM t2;
connection default;
--echo # Connection: default
source include/show_binlog_events.inc;
disconnect truncate;
DROP TABLE t1,t2;