Bug #20043 INSERT DELAYED with auto_increment discards row, binlog wrong (RBR and SBR)
Submitted: 24 May 2006 14:29 Modified: 3 Jul 2006 14:46
Reporter: Guilhem Bichot
Status: Duplicate
Category:Server: General Severity:S3 (Non-critical)
Version:5.1-bk OS:Linux (linux)
Assigned to: Guilhem Bichot Target Version:

[24 May 2006 14: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 13:56] Peter Olsen
Check out bug #20195
[2 Jun 2006 14: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 14: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.