Bug#55478 Row events wrongly apply on the temporary table of the same name

Rows events were applied wrongly on the temporary table with the same name.
But rows events are generated only for base tables. As temporary
table's data never be binlogged on row mode. Normally, base table of the
same name cannot be updated if a temporary table has the same name.
But there are two cases which can generate rows events on 
the base table of same name.
      
Case1: 'CREATE TABLE ... SELECT' statement.
In mixed format, it will generate rows events if it is unsafe.
      
Case2: Drop a transactional temporary table in a transaction
       (happens only on 5.5+).
BEGIN;
DROP TEMPORARY TABLE t1;       # t1 is a InnoDB table
INSERT INTO t1 VALUES(rand()); # t1 is a MyISAM table
COMMIT;
'DROP TEMPORARY TABLE' will be put in the transaction cache and
binlogged after the rows events generated by the 'INSERT' statement.
      
After this patch, slave opens only base table when applying a rows event.

1 files changed, 1 insertions, 0 deletions

diff --git a/sql/log_event.cc b/sql/log_event.cc
index 49f47edad72..041f90a057f 100644
--- a/sql/log_event.cc
+++ b/sql/log_event.cc
@@ -8258,6 +8258,7 @@ int Table_map_log_event::do_apply_event(Relay_log_info const *rli)
                 m_field_metadata, m_field_metadata_size,
                 m_null_bits, m_flags);
     table_list->m_tabledef_valid= TRUE;
+    table_list->skip_temporary= 1;
 
     /*
       We record in the slave's information that the table should be