Bug#33329 extraneous ROLLBACK in binlog on connection
does not use trans tables There had been two issues. Rollback statement was recorded in binlog even though a multi-update had not modified any non-transactional table. The reason for this artifact was a false initial value of multi_update::transactional_tables. Yet another artifact that explained on the bug page is that `ha_autocommit_or_rollback' works differently depending on whether a transaction engine has been compiled in. Fixed: with setting multi_update::transactional_tables to zero at initialization time. Multi-update on non-trans table won't cause ROLLBACK in binlog with either compilation option. The 2nd mentioned artifact comprises a self-standing issue (to be reported separately). mysql-test/r/multi_update.result: results changed - there is no ROLLBACK in binlog anymore as it should be sql/sql_update.cc: A wrong assumption on that there were modified transactional table, which is nonsense at the very beginning of the query execution.
Showing
Please register or sign in to comment