Bug #55869 In mixed mode, the Table_map_event is binloged without any rows_log_event.
Submitted: 10 Aug 2010 2:21 Modified: 10 Jan 2013 11:32
Reporter: Daogang Qu Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.5, 5.1 OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Tags: extra table_map

[10 Aug 2010 2:21] Daogang Qu
Description:
In mixed mode, the Table_map_event is binlogged without any rows_log_event
when a statement corrupted. It's a wrong behavior.

How to repeat:
binlog__trans_log.test:

--source include/have_innodb.inc
--source include/have_binlog_format_mixed.inc

delimiter |;

--disable_warnings
drop function if exists func|
drop table if exists t1,t2|
--enable_warnings
CREATE TABLE t1 (a int  NOT NULL auto_increment primary key) ENGINE=MyISAM|
CREATE TABLE t2 (a int  NOT NULL auto_increment, b int, PRIMARY KEY (a)) ENGINE=InnoDB|

insert into t2 values (1,1)|

create function func()
RETURNS int(11)
DETERMINISTIC
begin
  insert into t1 values (null);
  select count(*) from t1 into @a;
  return @a;
end|

reset master|

--error ER_DUP_ENTRY
insert into t2 values (func(),1)|
# the following must show there are events after the query
--source include/show_binlog_events.inc
select count(*),@a from t1 /* must be 1,1 */|

delimiter ;|

# clean-up

drop table t1,t2;
drop function if exists func;

Result:
master-bin.000001       #       Query   #       #       BEGIN
master-bin.000001       #       Table_map       #       #       table_id: # (test.t2)
master-bin.000001       #       Query   #       #       ROLLBACK

Suggested fix:
Don't binlog the Table_map_event without any Rows_log_event.
[10 Aug 2010 16:53] Sveta Smirnova
Thank you for the report.

Verified as described.
[27 Sep 2010 4:07] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/119132

3299 Dao-Gang.Qu@sun.com	2010-09-27
      Bug #55869  	In mixed mode, the Table_map_event is binloged without any rows_log_event.
      
      In mixed mode, the Table_map_event is binlogged without any rows_log_event
      when a unsafe single statement transaction corrupted. It's a wrong behavior.
      The reason is that the Table_map_event will be binlogged with the "ROLLBACK"
      Query_log_event together for a unsafe single stmt transaction, which has
      updated non-transactional table regardless of corruption.
      
      To fix the problem to not binlog the Table_map_event and "ROLLBACK"
      Query_log_event for a unsafe corrupted single stmt transaction,
      although it has updated non-transactional table.
     @ mysql-test/suite/binlog/r/binlog_trans_log.result
        Test result for Bug #55869.
     @ mysql-test/suite/binlog/t/binlog_trans_log.test
        Added the test to verify if Table_map_event is binlogged without
        any rows_log_event for a unsafe corrupted single stmt transaction,
        although it has updated non-transactional table.
[11 Oct 2010 2:52] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/120451

3299 Dao-Gang.Qu@sun.com	2010-10-11
      Bug #55869  	In mixed mode, the Table_map_event is binloged without any rows_log_event.
      
      In mixed mode, the Table_map_event is binlogged without any rows_log_event
      when a unsafe single statement transaction corrupted. It's a wrong behavior.
      The reason is that the Table_map_event will be binlogged with the "ROLLBACK"
      Query_log_event together for a unsafe single stmt transaction, which has
      invoked a function to execute non-transactional statement but its rows events
      have been written into stmt catch instead of trans catch before corruption.
      
      To fix the problem to create a flag to identify if a non-transactional
      statement is written to the trx-cache. If the flag is true, the content
      of the trx-cache is flushed, otherwise, it is discarded.
     @ mysql-test/suite/binlog/r/binlog_trans_log.result
        Test result for Bug #55869.
     @ mysql-test/suite/binlog/t/binlog_trans_log.test
        Added the test to verify if Table_map_event is binlogged without
        any rows_log_event for a unsafe corrupted single stmt transaction,
        although it has updated non-transactional table.
     @ sql/binlog.cc
        Added code to flush the content of the trx-cache for single statement
        transaction if a non-transactional statement is written to the trx-cache.
[15 Oct 2010 10:51] Daogang Qu
It will be fixed in Wl#5620.
[10 Jan 2013 11:32] Erlend Dahl
Re-verified this in 5.5.30, but it has apparently been fixed in 5.6.10. Closing as "can't repeat".