mirror of
https://github.com/MariaDB/server.git
synced 2025-01-31 02:51:44 +01:00
1b74f2e3da
WRITTEN WHILE ROWS REMAINS Problem: ======== When truncate table fails while using transactional based engines even though the operation errors out we still continue and log it to binlog. Because of this master has data but the truncate will be written to binary log which will cause inconsistency. Analysis: ======== Truncate table can happen either through drop and create of table or by deleting rows. In the second case the existing code is written in such a way that even if an error occurs the truncate statement will always be binlogged. Which is not correct. Binlogging of TRUNCATE TABLE statement should check whether truncate is executed "transactionally or not". If the table is transaction based we log the TRUNCATE TABLE only on successful completion. If table is non transactional there are possibilities that on error we could have partial changes done hence in such cases we do log in spite of errors as some of the lines might have been removed, so the statement has to be sent to slave. Fix: === Using table handler whether truncate table is being executed in transaction based mode or not is identified and statement is binlogged accordingly. mysql-test/suite/binlog/r/binlog_truncate_kill.result: Added test case to test the fix for Bug#17942050. mysql-test/suite/binlog/t/binlog_truncate_kill.test: Added test case to test the fix for Bug#17942050. sql/sql_truncate.cc: Check if truncation is successful or not and retun appropriate return values so that binlogging can be done based on that. sql/sql_truncate.h: Added a new enum. |
||
|---|---|---|
| .. | ||
| binlog | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| innodb | ||
| innodb_zip | ||
| jp | ||
| large_tests | ||
| manual | ||
| parts | ||
| perfschema | ||
| perfschema_stress | ||
| rpl | ||
| stress | ||
| sys_vars | ||