Details
Technical task
Minor
Description
If an explicit value (bigger than existing values) is inserted into an auto-increment column of a LevelDB table, the AUTO_INCREMENT doesn't get increased, so the next attempt to use it causes a duplicate key error.
With InnoDB it works as expected (the value grows).
mysql> create table t1 (pk int auto_increment primary key) engine=LevelDB; Query OK, 0 rows affected (0.03 sec) mysql> insert into t1 values (null); Query OK, 1 row affected (0.00 sec) mysql> insert into t1 values (2); Query OK, 1 row affected (0.00 sec) mysql> show create table t1; +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ | t1 | CREATE TABLE `t1` ( `pk` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`pk`) ) ENGINE=LEVELDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1 | +-------+-------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> insert into t1 values (null); ERROR 1062 (23000): Duplicate entry '2' for key 'PRIMARY' mysql>
revision-id: psergey@askmonty.org-20130208190127-uq98t2n3jl85c50r revno: 4595 branch-nick: mysql-5.6-leveldb
Test case:
create table t1 (pk int auto_increment primary key) engine=LevelDB; insert into t1 values (null); show create table t1; insert into t1 values (2); show create table t1; insert into t1 values (null);
Also covered in leveldb.autoincrement test, only there it causes a result mismatch rather than ER_DUP_ENTRY because the test uses a non-unique index for the column.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The above might be ok actually. I'll need to debug auto_increment code further to find out.
Debugging the statement
insert into t1 values (2);
I find that execution reaches this function
void handler::adjust_next_insert_id_after_explicit_value(ulonglong nr)
{
/*
If we have set THD::next_insert_id previously and plan to insert an
explicitely-specified value larger than this, we need to increase
THD::next_insert_id to be greater than the explicit value.
*/
if ((next_insert_id > 0) && (nr >= next_insert_id))
set_next_insert_id(compute_next_insert_id(nr, &table->in_use->variables));
}
and there, nr=<2, or whatever I have specified>, next_insert_id=0.
Since next_insert_id==0, the value is not updated.