[MDEV-29757] Table AUTO_INCREMENT set to higher value than it should be for no apparent reason Created: 2022-10-10 Updated: 2023-11-28 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10 |
| Fix Version/s: | 10.4, 10.5, 10.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Marko Mäkelä |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
So, while all 100 rows are inserted without gaps, the table AUTO_INCREMENT is set to a much higher value, and it is indeed used on the next INSERT, it will start from 128. Modifying the test case to continue inserting:
So again, it lost 27 values while setting the new AUTO_INCREMENT. Even stranger, seemingly unrelated tables can affect it:
Here it is the same 128
But
here it is already 132:
(and the unrelated table isn't even necessarily InnoDB). Reproducible with innodb-autoinc-lock-mode=1|2 (default is 1). Not reproducible with innodb-autoinc-lock-mode=0. Not reproducible with MyISAM. |
| Comments |
| Comment by Marko Mäkelä [ 2022-10-10 ] |
|
This is related to the way how auto-increment values are being allocated in batches. Can you reproduce this when using INSERT…VALUES? |
| Comment by Elena Stepanova [ 2022-10-10 ] |
|
I'm not planning to dive into legacy auto-increment testing in its various aspects any time soon, so you can consider this report to be about INSERT .. SELECT and close it as "won't fix" if that's the plan. It seems to be a rather wasteful way to allocate values, and I don't quite understand how allocating in batches explains the dependency on an unrelated table, but I suppose until it bothers real users, it's not important enough to argue about. |