Bug #20043 INSERT DELAYED with auto_increment discards row, binlog wrong (RBR and SBR)
Submitted: 24 May 2006 12:29 Modified: 3 Jul 2006 12:46
Reporter: Guilhem Bichot Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: General Severity:S3 (Non-critical)
Version:5.1-bk OS:Linux (linux)
Assigned to: Assigned Account CPU Architecture:Any

[24 May 2006 12:29] Guilhem Bichot
Description:
running "how-to-repeat", the results are:
+---+------+
| a | b    |
+---+------+
| 1 |  500 |
| 2 |  600 |
| 3 | 2000 |
| 4 | 3000 |
+---+------+
That is, row "1000" was not inserted. The binary log shows:
| gbichot2-bin.000009 | 102 | Query       |         1 |         188 | use `test`; drop table if exists t1                                                                                                    |
| gbichot2-bin.000009 | 188 | Query       |         1 |         373 | use `test`; CREATE TABLE `t1` (
  `a` int(11) NOT NULL AUTO_INCREMENT,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`)
) ENGINE=MyISAM |
| gbichot2-bin.000009 | 373 | Intvar      |         1 |         401 | INSERT_ID=1                                                                                                                            |
| gbichot2-bin.000009 | 401 | Query       |         1 |         504 | use `test`; insert delayed into t1 values(null, 500)                                                                                   |
| gbichot2-bin.000009 | 504 | Intvar      |         1 |         532 | INSERT_ID=2                                                                                                                            |
| gbichot2-bin.000009 | 532 | Query       |         1 |         626 | use `test`; insert into t1 values(null,600)                                                                                            |
| gbichot2-bin.000009 | 626 | Intvar      |         1 |         654 | INSERT_ID=4                                                                                                                            |
| gbichot2-bin.000009 | 654 | Query       |         1 |         757 | use `test`; insert delayed into t1 values(null,3000)                                                                                   |
| gbichot2-bin.000009 | 757 | Query       |         1 |         832 | use `test`; flush tables                                                                                                               |
Row "1000" is absent from binlog and table. Row "2000" is present in table and absent from binlog. 
1) we cannot see why 1000 was not inserted as no "duplicate key" can happen as we insert an autogenerated value in the auto_increment column.
2) even admitting 1, point-in-time recovery from statement-based binlogs, and replication, will break.
If using row-based binlogging, the binlog has:
| gbichot2-bin.000010 | 102 | Query       |         1 |         188 | use `test`; drop table if exists t1                                                                                                    |
| gbichot2-bin.000010 | 188 | Query       |         1 |         373 | use `test`; CREATE TABLE `t1` (
  `a` int(11) NOT NULL AUTO_INCREMENT,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`)
) ENGINE=MyISAM |
| gbichot2-bin.000010 | 373 | Table_map   |         1 |         413 | table_id: 39 (test.t1)                                                                                                                 |
| gbichot2-bin.000010 | 413 | Table_map   |         1 |         453 | table_id: 39 (test.t1)                                                                                                                 |
| gbichot2-bin.000010 | 453 | Write_rows  |         1 |         491 | table_id: 39 flags: STMT_END_F                                                                                                         |
| gbichot2-bin.000010 | 491 | Write_rows  |         1 |         529 | table_id: 39 flags: STMT_END_F                                                                                                         |
| gbichot2-bin.000010 | 529 | Table_map   |         1 |         569 | table_id: 39 (test.t1)                                                                                                                 |
| gbichot2-bin.000010 | 569 | Write_rows  |         1 |         616 | table_id: 39 flags: STMT_END_F                                                                                                         |
| gbichot2-bin.000010 | 616 | Query       |         1 |         691 | use `test`; flush tables
and replaying it with mysqlbinlog yields:
+---+------+
| a | b    |
+---+------+
| 1 |  500 |
| 3 | 2000 |
| 4 | 3000 |
+---+------+
where 600 is missing compared to the original run.

How to repeat:
#testcase:
drop table if exists t1;
CREATE TABLE `t1` (
  `a` int(11) NOT NULL AUTO_INCREMENT,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`)
) ENGINE=MyISAM;
insert delayed into t1 values(null, 500);
insert into t1 values(null,600);
select * from t1;
insert delayed into t1 values(null,1000);
insert delayed into t1 values(null,2000);
insert delayed into t1 values(null,3000);
select sleep(3); # in case the DELAYED take time
select * from t1;
flush tables; # additional safety to force the DELAYED to happen
select * from t1;
[1 Jun 2006 11:56] Peter Olsen
Check out bug #20195
[2 Jun 2006 12:12] Guilhem Bichot
The analysis made by Mr Olsen in BUG#20195 explains at least the absence of 1000 in the present bug report, and shows that my work on WL#3146 will not fix the problem (Wl#3146 does not change anything to delayed inserts). De-assigning it from me, so.
[3 Jul 2006 12:46] Guilhem Bichot
Now that BUG#20195 has been fixed, my testcase shows no more binlog problems.
So I close this bug as duplicate of BUG#20195.