BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables

BUG#54872 MBR: replication failure caused by using tmp table inside transaction 
      
Changed criteria to classify a statement as unsafe in order to reduce the
number of spurious warnings. So a statement is classified as unsafe when
there is on-going transaction at any point of the execution if:

1. The mixed statement is about to update a transactional table and
a non-transactional table.

2. The mixed statement is about to update a temporary transactional
table and a non-transactional table.
      
3. The mixed statement is about to update a transactional table and
read from a non-transactional table.

4. The mixed statement is about to update a temporary transactional
table and read from a non-transactional table.

5. The mixed statement is about to update a non-transactional table
and read from a transactional table when the isolation level is
lower than repeatable read.

After updating a transactional table if:

6. The mixed statement is about to update a non-transactional table
and read from a temporary transactional table.
 
7. The mixed statement is about to update a non-transactional table
 and read from a temporary transactional table.

8. The mixed statement is about to update a non-transactionala table
   and read from a temporary non-transactional table.
     
9. The mixed statement is about to update a temporary non-transactional
table and update a non-transactional table.
     
10. The mixed statement is about to update a temporary non-transactional
table and read from a non-transactional table.
     
11. A statement is about to update a non-transactional table and the
option variables.binlog_direct_non_trans_update is OFF.

The reason for this is that locks acquired may not protected a concurrent
transaction of interfering in the current execution and by consequence in
the result. So the patch reduced the number of spurious unsafe warnings.

Besides we fixed a regression caused by BUG#51894, which makes temporary
tables to go into the trx-cache if there is an on-going transaction. In
MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have
updates to temporary non-transactional tables that must be written to the
binary log while rolling back the transaction.
      
So we fix this problem by writing the content of the trx-cache to the
binary log while rolling back a transaction if a non-transactional
temporary table was updated and the binary logging format is MIXED.

1 files changed, 2 insertions, 2 deletions

diff --git a/mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test b/mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test
index dd5f9907a21..1fb6b3dcb8a 100644
--- a/mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test
+++ b/mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test
@@ -77,11 +77,11 @@ eval UPDATE t2, t1 SET t2.data = CONCAT($data, $data, $data, $data),
 connection slave;
 --source include/wait_for_slave_sql_to_stop.inc
 
-if (`SELECT @@binlog_format = 'STATEMENT'`)
+if (`SELECT @@binlog_format = 'STATEMENT' || @@binlog_format = 'MIXED'`)
 {
   SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
 }
-if (`SELECT @@binlog_format = 'ROW' || @@binlog_format = 'MIXED'`)
+if (`SELECT @@binlog_format = 'ROW'`)
 {
   SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2;
 }