Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
-
None
Description
probably 5.5 is affected too, I didn't check
this is the test case:
--source include/have_innodb.inc
|
create or replace table t1 (pk int auto_increment primary key, f varchar(20)) engine=innodb; |
insert t1 (f) values ('a'), ('b'), ('c'), ('d'); |
select null, f into outfile 'load.data' from t1 limit 2; |
load data infile 'load.data' into table t1; |
insert t1 (f) values ('<==='); |
select * from t1; |
drop table t1; |
What happens here, insert tells the engine to reserve 4 auto-increment values. This "4" number is never reset, so the following load data also reserves four values, even if it needs only two. And the next insert creates a gap in the auto-increment sequence.
Most engines do not reserve auto-increment values, and generate one value at a time. So with MyISAM, for example, there is no gap in this test.
The fix would be to reset the list at the end of the insert statement.
Attachments
Issue Links
- is duplicated by
-
MDEV-17455 Slave data corruption when master is MySQL 5.5 in STATEMENT
-
- Closed
-
- relates to
-
MDEV-17455 Slave data corruption when master is MySQL 5.5 in STATEMENT
-
- Closed
-
-
MDEV-17333 Assertion in update_auto_increment() upon exotic LOAD
-
- Closed
-
The suggested fix fails for this (rpl.rpl_auto_increment,innodb,mix):
Failure details
I'd suggest:
Longer fix (for 10.3 and lower appropriate versions)
Expand Sql_cmd hierarchy for INSERT command and isolate its private data such as LEX::many_values, LEX::insert_list, LEX::field_list, LEX::values_list as well as interface tvc_start(), tvc_finalize(), tvc_finalize_derived() (and whatever else).
This would work because Sql_cmd lifetime will be for parsed trigger, not for single INSERT statement.
Shorter fix (for versions where Longer fix is impossible)
Check for sql_command around many_values.