Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
5.5.28, 5.3.8, 5.2.13, 5.1.62
-
None
-
None
-
All
Description
When one inserts a row into a table with auto-increment, the error message
can be confusing:
create table t1 (a smallint primary key auto_increment);
insert into t1 values(32767);
insert into t1 values(NULL);
ERROR 1062 (23000): Duplicate entry '32767' for key 'PRIMARY
In some cases on gets:
ERROR 1264 (22003): Out of range value for column 'id' at row 1
or there is a warning about the "out of range".
This depends on SQL Mode, engine used or if one inserts one or multiple row at a time.
Inserting negative numbers for the auto increment columns also works differently between engines.
The task is to ensure that all engines works exactly the same way and that one will always get:
ERROR 1264 (22003): Out of range value for column
when an auto increment overflows.
To fix this one need to do changes in sql/handler.cc
and in innodb/xtradb.
Because of how the auto_increment checking is done, we can fix all issues
except for the case of inserting a generated max bigint unsigned value (18446744073709551615).
In this case all engines will report:
"Failed to read auto-increment value from storage engine"
To fix this would require a handler interface change that I am not confident in doing in 5.5
In additional this would be hard to fix this in InnoDB as stores 'the next number to be used'. This means we can't distinguish between inserting the max possible number or if there is still room for the max number.
Another effect of this is that for columns of type bigint unsigned, the max generated auto increment value is 18446744073709551614
Regarding the comment about that we now get an out-of-range error when trying to do insert a too big value in an auto-increment column instead of getting the 'max allowed value' inserted.
I see this as a bug fix and the old behavior was wrong; We should never inserted a smaller number than requested as this could break replication in some scenarios.
This also fixes the case when reset a table by dropping and recreating with specific AUTO_INCREMENT=xxx in the CREATE statement.
With the old code we would have inserted an already used value. Now you will get an error if the first value is out of range.