BUG#54842: DROP TEMPORARY TABLE not binlogged after manual
switching binlog format to ROW BUG 52616 fixed the case which the user would switch from STMT to ROW binlog format, but the server would silently ignore it. After that fix thd->is_current_stmt_binlog_format_row() reports correct value at logging time and events are logged in ROW (as expected) instead of STMT as they were previously and wrongly logged. However, the fix was only partially complete, because on disconnect, at THD cleanup, the implicit logging of temporary tables is conditionally performed. If the binlog_format==ROW and thd->is_current_stmt_binlog_format_row() is true then DROPs are not logged. Given that the user can switch from STMT to ROW, this is wrong because the server cannot tell, just by relying on the ROW binlog format, that the tables have been dropped before. This is effectively similar to the MIXED scenario when a switch from STMT to ROW is triggered. We fix this by removing this condition from close_temporary_tables. mysql-test/extra/binlog_tests/drop_temp_table.test: Added binlog test case. mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result: Result changes because: - there is a missing drop on three temporary tables - it now contains results for the test added mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Result now contains the implicit drop for the temporary table. mysql-test/suite/binlog/r/binlog_stm_drop_tmp_tbl.result: Result file changed because it now contains results for added test case. mysql-test/suite/rpl/r/rpl_drop_temp.result: Result file changed because it now contains results for added test case. mysql-test/suite/rpl/t/rpl_drop_temp.test: Added replication test case. sql/sql_base.cc: Removed the condition that would make the server to skip logging implicit drops when ROW binary log format mode was in use. Additionally, deployed DBUG_ENTER/RETURN macros.
Showing
Please register or sign in to comment