BUG#53560 CREATE TEMP./DROP TEMP. are not binglogged correctly after a failed statement
This patch fixes two problems described as follows: 1 - If there is an on-going transaction and a temporary table is created or dropped, any failed statement that follows the "create" or "drop commands" triggers a rollback and by consequence the slave will go out sync because the binary log will have a wrong sequence of events. To fix the problem, we changed the expression that evaluates when the cache should be flushed after either the rollback of a statment or transaction. 2 - When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the OPTION_KEEP_LOG was not set into the thd->options. For that reason, if the transaction had updated only transactional engines and was rolled back at the end (.e.g due to a deadlock) the changes were not written to the binary log, including the creation of the temporary table. To fix the problem, we have set the OPTION_KEEP_LOG into the thd->options when a "CREATE TEMPORARY TABLE SELECT * FROM" is executed.
Showing
Please register or sign in to comment