BUG#51251: Wrong binlogging in case of TRUNCATE <temporary InnoDB table>
For temporary tables that are created with an engine that does not provide the HTON_CAN_RECREATE, the truncate operation is performed resorting to the optimized handler::ha_delete_all_rows method. However, this means that the truncate will share execution path, from mysql_delete, with truncate on regular tables and other delete operations. As a consequence the truncate operation, for the temporary table is logged, even if in row mode because there is no distinction between this and the other delete operations at binlogging time. We fix this by checking if: (i) the binlog format, when the truncate operation was issued, is ROW; (ii) if the operation is a truncate; and (iii) if the table is a temporary table; before writing to the binary log. If all three conditions are met, we skip writing to the binlog. A side effect of this fix is that we limit the scope of setting and resetting the current_stmt_binlog_row_based. Now we just set and reset it inside mysql_delete in the boundaries of the handler::ha_write_row loop. This way we have access to thd->current_stmt_binlog_row_based real value inside mysql_delete. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Updated result for spurious truncate table. mysql-test/suite/binlog/t/binlog_row_innodb_truncate.test: Test case. sql/sql_delete.cc: Added check in mysql_delete before writing the TRUNCATE statement to the binary log. Additionally, removed the set/reset of current_stmt_binlog_row_based so that it happens just in the boundaries of the handler::ha_write_row loop inside mysql_delete.
Showing
Please register or sign in to comment