Bug #22742 extraneous table_map events with insert delayed
Submitted: 27 Sep 2006 15:24 Modified: 29 Jun 2011 13:36
Reporter: Andrei Elkin Email Updates:
Status: Can't repeat Impact on me:
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S2 (Serious)
Version:5.1.12,5.1.40 OS:Linux (linux)
Assigned to: Mats Kindahl CPU Architecture:Any

[27 Sep 2006 15:24] Andrei Elkin
execution of binlog_row_binlog -> extra/binlog_tests/ binlog -> binlog_insert_delayed results with the number of table_map events does not match to the number of insert delayed queries. It also impossible to predict how 
many table maps are come out on different platforms even though the number of inserted rows remain the same and there is no concurrent connections.

This is as least suboptimal, and makes SHOW BINLOG indeterministic useless
for replication tests.

How to repeat:
# just to show table_maps do not match the inserts one-by-one
This a part of  extra/binlog_tests/binlog_insert_delayed.test

create table t1 (a int not null auto_increment, primary key (a)) engine=myisam;
insert delayed into t1 values (null),(null);
show binlog events from 102;

# two table maps generated

 | dsl-hkigw8-feb9fb00-191-bin.000001 | 487 | Table_map   |         1 |         526 | table_id: 15 (test.t1)                           |
| dsl-hkigw8-feb9fb00-191-bin.000001 | 526 | Write_rows  |         1 |         560 | table_id: 15 flags: STMT_END_F                   |
| dsl-hkigw8-feb9fb00-191-bin.000001 | 560 | Table_map   |         1 |         599 | table_id: 15 (test.t1)                           |
| dsl-hkigw8-feb9fb00-191-bin.000001 | 599 | Write_rows  |         1 |         633 | table_id: 15 flags: STMT_END_F

Suggested fix:
examine the stack responsible for extra table_map to find out
what makes the code to think that the statement ends.

    (anonymous namespace)::write_locked_table_maps
    (anonymous namespace)::binlog_log_row<Write_rows_log_event>
[28 Sep 2006 1:56] MySQL Verification Team
Thank you for the bug report.
[13 Nov 2009 14:07] MySQL Verification Team
the fact that insert delayed totally breaks replication means that anybody using binlog_format=row and does insert delayed will have an unusable slave.

Testing:  setup a working master/slave with RBR and run on master:

drop table if exists t1;
create table t1(a int,primary key(a))engine=myisam;
insert delayed into t1 values (3),(4),(5);
insert delayed into t1 values (6),(7),(8);
delete from t1 where a>7;
update t1 set a=a*10 where a<4;

Slave breaks and gets totally out of sync:
91113 16:03:28 [ERROR] Slave SQL: Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log xp64-bin.000001, end_log_pos 448, Error_code: 1032
91113 16:03:28 [Warning] Slave: Can't find record in 't1' Error_code: 1032
91113 16:03:28 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'xp64-bin.000001' position 305
[29 Jun 2011 13:36] Jon Stephens
Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php

If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.