Bug #16979 AUTO_INC lock in InnoDB works a table level lock
Submitted: 31 Jan 2006 15:43 Modified: 20 Jun 2010 17:27
Reporter: Gleb Paharenko Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S5 (Performance)
Version:5.0.18 OS:Any (All)
Assigned to: Sunny Bains CPU Architecture:Any

[31 Jan 2006 15:43] Gleb Paharenko
Description:
It is documented, and I was told in public developers list that AUTO_INC lock works as table level lock. It means that if I have a long statement which hods this lock (say a huge INSERT into the table with auto_increment field), other threads can't perfrom an insert in this table.

How to repeat:
http://dev.mysql.com/doc/refman/5.0/en/innodb-auto-increment-column.html
" When accessing the auto-increment counter, InnoDB uses a special table-level AUTO-INC lock that it keeps to the end of the current SQL statement, "

Suggested fix:
Fix this so concurrent inserts can work in parrallel mode on tables with auto_increment field
[31 Jan 2006 22:42] Heikki Tuuri
Gleb,

it is necessary with the current logical binlogging of MySQL, since the auto-inc values assigned in a single SQL statement must be consecutive.

An optimization for single-line INSERTs could be possible, but in those cases the auto-inc lock is not that big a bottleneck.

With the row-based replication of 5.1, it is possible to get rid of the auto-inc lock altogether.

Regards,

Heikki
[2 Feb 2006 14:44] Heikki Tuuri
Assigning this to Jan Lindström. This should be fixed in 5.1.

The fix:

"
If the user user row-based binlogging in 5.1, we can completely abolish the auto-inc lock in InnoDB. To that end, Jan should add a new global variable:

ibool srv_auto_inc_locks  = TRUE; /* if TRUE, use a statement-length
                table lock on the auto-inc counter;
                this is used by MySQL's logical
                binlogging */

to srv0srv.c. Then put all auto-inc lock operations in ha_innodb.cc behind the test:

if (srv_auto_inc_locks) {
    /* Set or release an auto-inc lock on a table */
}

When row-based binlogging is used, set:

srv_auto_inc_locks = TRUE;

in the InnoDB startup in ha_innodb.cc. 
"

Regards,

Heikki
[2 Feb 2006 16:21] Heikki Tuuri
Looking at the handler.cc code, I see that our simple solution that I outlined is not going to work! The problem is that handler.cc in a multi-row SQL statement calls ::get_auto_increment() only for the FIRST row in the statement. After that, it increments the value internally, without asking InnoDB at all.

Thus, to get this to work, also handler.cc should be changed in some way, so that it would call ::get_auto_increment() for all rows if row-based binlogging is used for all sessions.

And InnoDB should in ::get_auto_increment() actually increment the counter by one, something InnoDB does not do currently.

A further challenge is that the logic of assigning the next auto-increment number based on an increment and offset must be moved down to ha_innodb.cc.

handler.cc in 5.0.18:
"
/*
  Generate the next auto-increment number based on increment and offset

  In most cases increment= offset= 1, in which case we get:
  1,2,3,4,5,...
  If increment=10 and offset=5 and previous number is 1, we get:
  1,5,15,25,35,...
*/

inline ulonglong
next_insert_id(ulonglong nr,struct system_variables *variables)
{
  nr= (((nr+ variables->auto_increment_increment -
         variables->auto_increment_offset)) /
       (ulonglong) variables->auto_increment_increment);
  return (nr* (ulonglong) variables->auto_increment_increment +
          variables->auto_increment_offset);
}
"
[3 Feb 2006 13:01] Ady Wicaksono
Hi Gleb,

I Agree with you.... this problem is bad. CONCURRENT INSERT on InnoDB could be failed if a thread is doing table lock (LOCK AUTO-INC).

Example like my problem below, there're 4 threads doing commit data, another threads trying to insert data, another threads is doing select count(*) on table.

Problem arise because 4 threads which doing commit data is not finished on the gracefull time, so another threads which trying to insert data finally failed
with Deadlock found...bla bla.. try restart transaction

Finally, i want to remove auto_increment in my table because of this problem.

mysql> desc sms_telkomsel.t_outgoing_sms_3t;
+-------------------------------+--------------+------+-----+---------------------+----------------+
| Field                         | Type         | Null | Key | Default             | Extra          |
+-------------------------------+--------------+------+-----+---------------------+----------------+
| out_sms_id                    | int(11)      | NO   | PRI | NULL                | auto_increment |
| out_sms_time                  | timestamp    | YES  | MUL | CURRENT_TIMESTAMP   |                |
| out_sms_dest                  | varchar(16)  | NO   | MUL |                     |                |
| out_sms_msg                   | varchar(160) | NO   |     |                     |                |
| out_sms_status                | tinyint(2)   | NO   | MUL | 0                   |                |
| out_sms_typePremium           | varchar(26)  | NO   | MUL |                     |                |
| out_sms_trx_id                | varchar(40)  | NO   | MUL |                     |                |
| out_sms_trx_date              | varchar(33)  | NO   |     |                     |                |
| out_sms_typeService_telkomsel | varchar(20)  | NO   |     |                     |                |
| out_sms_pin_quiz              | varchar(15)  | NO   |     |                     |                |
| out_sms_quiz_keycode          | varchar(20)  | NO   | MUL |                     |                |
| out_sms_quiz_answer           | varchar(160) | NO   | MUL |                     |                |
| in_sms_message_id             | varchar(22)  | NO   |     |                     |                |
| in_sms_time                   | datetime     | NO   | MUL | 0000-00-00 00:00:00 |                |
| in_sms_smsc_seq_number        | int(11)      | NO   | MUL | 0                   |                |
| out_sms_city                  | varchar(50)  | NO   | MUL |                     |                |
+-------------------------------+--------------+------+-----+---------------------+----------------+
16 rows in set (0.07 sec)

INNODB status attached on files
[3 Feb 2006 13:05] Ady Wicaksono
----------- 4 threads commit data ----------
MySQL thread id 21144, query id 14725009 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5bdf9b67R','2006-02-03 19:06:52','2006-02-03 19:06:52','6281337021463','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5bdf9b67R',1,'TELKOMSEL2000','8770060','20060203190623','3T','5bdf9b67R','3T','tikar','DENPASAR')
---TRANSACTION 0 447488156, COMMITTED IN MEMORY, process no 26304, OS thread id 3017668672 committing
mysql tables in use 1, locked 1
, undo log entries 1
MySQL thread id 20340, query id 14725030 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5bdebbb2L','2006-02-03 19:06:52','2006-02-03 19:06:52','6281361535798','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5bdebbb2L',1,'TELKOMSEL2000','8770048','20060203190623','3T','5bdebbb2L','3T','','MEDAN')
---TRANSACTION 0 447488155, COMMITTED IN MEMORY, process no 26304, OS thread id 3168990784 committing
mysql tables in use 1, locked 1
, undo log entries 1
MySQL thread id 21119, query id 14725026 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5b9cdb06P','2006-02-03 19:06:52','2006-02-03 19:06:52','6281365745460','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5b9cdb06P',1,'TELKOMSEL2000','8770033','20060203120623','3T','5b9cdb06P','3T','','PEKANBARU')
---TRANSACTION 0 447488154, COMMITTED IN MEMORY, process no 26304, OS thread id 3159928128 committing
mysql tables in use 1, locked 1
, undo log entries 1
MySQL thread id 20553, query id 14725024 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5acf6a99P','2006-02-03 19:06:52','2006-02-03 19:06:52','628128022607','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5acf6a99P',1,'TELKOMSEL2000','8769928','20060203120622','3T','5acf6a99P','3T','TIKAR','JAKARTA')
---TRANSACTION 0 447488153, COMMITTED IN MEMORY, process no 26304, OS thread id 3045035072 committing

----------- 4 threads commit data ----------
[3 Feb 2006 13:05] Ady Wicaksono
MySQL thread id 21193, query id 14725264 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5c082d29H','2006-02-03 19:06:52','2006-02-03 19:06:52','6281347110400','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5c082d29H',1,'TELKOMSEL2000','8770010','20060203120623','3T','5c082d29H','3T','','BALIKPAPAN')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488307 lock mode AUTO-INC waiting
------------------
---TRANSACTION 0 447488305, ACTIVE 1 sec, process no 26304, OS thread id 2946291520 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 1 lock struct(s), heap size 320
MySQL thread id 21113, query id 14725263 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5c1c09c8V','2006-02-03 19:06:52','2006-02-03 19:06:52','62811639647','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5c1c09c8V',1,'TELKOMSEL2000','8770070','20060203120623','3T','5c1c09c8V','3T','','MEDAN')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488305 lock mode AUTO-INC waiting
------------------
---TRANSACTION 0 447488304, ACTIVE 1 sec, process no 26304, OS thread id 2954491200 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 1 lock struct(s), heap size 320
MySQL thread id 21096, query id 14725261 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5c3c39e3F','2006-02-03 19:06:53','2006-02-03 19:06:53','6281363435065','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5c3c39e3F',1,'TELKOMSEL2000','8770097','20060203190623','3T','5c3c39e3F','3T','','PADANG')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488304 lock mode AUTO-INC waiting
------------------
---TRANSACTION 0 447488301, ACTIVE 1 sec, process no 26304, OS thread id 2990665536 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 1 lock struct(s), heap size 320
MySQL thread id 20383, query id 14725247 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5c14e8d0P','2006-02-03 19:06:52','2006-02-03 19:06:52','628121346965','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5c14e8d0P',1,'TELKOMSEL2000','8770080','20060203190623','3T','5c14e8d0P','3T','','JAKARTA')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488301 lock mode AUTO-INC waiting
------------------
---TRANSACTION 0 447488300, ACTIVE 1 sec, process no 26304, OS thread id 3004300480 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 1 lock struct(s), heap size 320
MySQL thread id 20148, query id 14725248 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5bc09b43F','2006-02-03 19:06:52','2006-02-03 19:06:52','6285219065533','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5bc09b43F',1,'TELKOMSEL2000','8770041','20060203190623','3T','5bc09b43F','3T','','JAKARTA')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488300 lock mode AUTO-INC waiting
------------------
---TRANSACTION 0 447488299, ACTIVE 1 sec, process no 26304, OS thread id 3052598464 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 1 lock struct(s), heap size 320
MySQL thread id 21152, query id 14725251 10.1.20.10 root update
insert into sms_telkomsel.t_outgoing_sms_3t (in_sms_message_id, in_sms_time, out_sms_time,   out_sms_dest, out_sms_msg, out_sms_status,   out_sms_typePremium, out_sms_trx_id, out_sms_trx_date,  out_sms_typeService_telkomsel, out_sms_pin_quiz, out_sms_quiz_keycode,  out_sms_quiz_answer, out_sms_city)  values ('5bb7d450R','2006-02-03 19:06:52','2006-02-03 19:06:52','6285231060657','Terima kasih atas partisipasinya. Kirim terus SMS anda. PIN: 5bb7d450R',1,'TELKOMSEL2000','8769767','20060203190622','3T','5bb7d450R','3T','','SURABAYA')
------- TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `sms_telkomsel/t_outgoing_sms_3t` trx id 0 447488299 lock mode AUTO-INC waiting
[4 Feb 2006 21:07] Vadim Tkachenko
Heikki,

I proposed my patch for auto inc problem 8 month ago,
it replaces auto_inc lock for read_write_lock.
Maybe it is good solution?

(I'll attache patch to this bug)
[4 Feb 2006 21:07] Vadim Tkachenko
auto_inc patch

Attachment: auto_inc.diff (text/plain), 9.32 KiB.

[6 Feb 2006 9:57] Heikki Tuuri
Vadim,

thank you, your patch would help by making the AUTO-INC lock less restrictive: it could also be a read lock in some cases. But here we want to remove it altogether.

Regards,

Heikki
[6 Feb 2006 9:59] Heikki Tuuri
Vadim,

yes, and your patch would remove the lock for single-row INSERTs. That would be valuable. But anyway, Jan's task is to remove the lock altogether when row-based binlogging is used.

Regards,

Heikki
[20 Apr 2006 18:04] Eric DeCosta
I'm encountering this problem all to frequently and would be happy with a partial work-around for single-row inserts:

LATEST DETECTED DEADLOCK
------------------------
060420 13:26:04
*** (1) TRANSACTION:
TRANSACTION 0 44420604, ACTIVE 2 sec, process no 22480, OS thread id 2839792560 setting auto-inc lock
mysql tables in use 1, locked 1
LOCK WAIT 51 lock struct(s), heap size 11584, undo log entries 734
MySQL thread id 134, query id 244187 decostae02linux.dhcp 144.212.115.99 results update
INSERT INTO Test_File_Result (test_directory_result_id, test_file_id, test_status_id, start_offset) VALUES('1004453','11181','4',
'328198')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `test_results/Test_File_Result` trx id 0 44420604 lock mode AUTO-INC waiting
*** (2) TRANSACTION:
TRANSACTION 0 44420602, ACTIVE 2 sec, process no 22480, OS thread id 2839391152 inserting
mysql tables in use 1, locked 1
62 lock struct(s), heap size 11584, undo log entries 1402
MySQL thread id 133, query id 244185 decostae02linux.dhcp 144.212.115.99 results update
INSERT INTO Test_File_Result (test_directory_result_id, test_file_id, test_status_id, start_offset) VALUES('1004451','19287','4',
'482483')
*** (2) HOLDS THE LOCK(S):
TABLE LOCK table `test_results/Test_File_Result` trx id 0 44420602 lock mode AUTO-INC
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 870737 n bits 424 index `PRIMARY` of table `test_results/Test_File_Result` trx id 0 44420602 lock
_mode X locks gap before rec insert intention waiting
Record lock, heap no 356 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 4; hex 000f53a5; asc   S ;; 1: len 4; hex 00002bac; asc   + ;; 2: len 4; hex 009ed4d2; asc     ;; 3: len 6; hex 000002a5c
dfc; asc       ;; 4: len 7; hex 00000b00103109; asc      1 ;; 5: len 2; hex 0002; asc   ;; 6: len 4; hex 0004fe4e; asc    N;; 7:
len 4; hex 00050206; asc     ;; 8: len 4; hex 0000c040; asc    @;;

*** WE ROLL BACK TRANSACTION (1)
[2 May 2006 1:17] James Day
Heikki,

If the existing patch improves performance when row-level binlogging isn't being used it seems quite valuable and one I'd like to see. Having one improvement for each case would be useful because row-level is inappropriate for a significant number of cases, notably for users with multi-site setups over comparatively slow internet links.
[8 May 2006 5:34] Vadim Tkachenko
Patch for 5.0.21 tree

Attachment: auto_inc_5021.diff (application/octet-stream, text), 10.53 KiB.

[8 May 2006 5:35] Vadim Tkachenko
Hi,

I added patch for 5.0.21 tree.
To apply: patch -p1 < auto_inc_5021.diff in 5.0.21 directory
[13 May 2006 4:34] Vadim Tkachenko
new version of patch

Attachment: pa4.diff (text/plain), 11.52 KiB.

[2 Aug 2006 15:41] Vadim Tkachenko
Patch for 5.1

Attachment: patch.51.autoinc.diff (text/plain), 10.69 KiB.

[2 Aug 2006 15:43] Vadim Tkachenko
Heikki,

I added my patch for 5.1 tree,
but as I was reported this patch crashes server under high load,
so it should be tested or checked somehow...
[2 Aug 2006 15:47] Heikki Tuuri
Vadim,

yes, this is in the category of 'new feature' that do not happen quickly. It has to be checked carefully.

Note that 5.1 currently crashes under a high load even with no patches:
http://bugs.mysql.com/bug.php?id=20213

Regards,

Heikki
[1 Sep 2006 13:23] Heikki Tuuri
Since any fix to this problem changes the behavior in error cases (since we cannot restore the old counter value any more), we can only fix this in 5.1 or later.
[17 Oct 2006 11:22] Heikki Tuuri
Sunny is now studying this while he is tuning the fixes to the thread thrashing problem http://bugs.mysql.com/bug.php?id=22868

Sinisa has submitted several emails about how to fix AUTO-INC bottleneck problem.
[18 Jan 2007 16:15] Heikki Tuuri
A summary of some ideas: there are two easy solutions to the AUTO-INC contention:

1) Handle a single-row insert as a special case: we can release the AUTO-INC lock immediately. Downside: error handling will change for single-row inserts; we cannot roll back the change to the auto-inc counter if there is an error. Error handling can only be changed in a new major version like 5.1 or 5.2.

2) Use row-based binlogging in 5.1 and get rid of the AUTO-INC lock altogether. We could add a my.cnf option innodb_auto_inc whose default value would be 1, but the DBA could set it to 0 if he uses row-based binlogging.
[19 Jan 2007 15:19] MySQL Verification Team
Heikki,

In my opinion, your solution to single row inserts can be extended to multi-row inserts, but not to LOAD DATA. Simply, you can fetch  number of rows that are contained in a command from SQL layer, and reserve that many auto_inc's. If that insert has ON DUPLICATE UPDATE, that just means that there will be unused numbers, but that is not such a huge problem as this lock is. 

What do you think ???

Sinisa Milivojevic
[19 Jan 2007 15:30] Heikki Tuuri
Sinisa,

you have a brilliant idea for multi-row inserts where we know the number of the rows to be inserted, thank you. Like 1) above, this will change error handling slightly.

This bug has a connection to http://bugs.mysql.com/bug.php?id=22868. In some tests by Sunny, the contention in http://bugs.mysql.com/bug.php?id=22868 does come from the AUTO-INC lock.

Regards,

Heikki
[25 Jul 2007 17:06] Guilhem Bichot
when we implement a "new binlog event Insert_id_list_event to store multiple
auto_increment intervals" (unplanned, as far as I know; internally known as WL#3404), we will be able to do this (see handler::update_auto_increment() in 5.1):
- in a multi-row insert of N records, InnoDB's get_auto_increment() will be asked to reserve N autoinc values
- in a INSERT SELECT or LOAD DATA INFILE, the number of records to insert is often unknown, but InnoDB's get_auto_increment() will be asked to reserve a bunch of consecutive values (an interval) (containing some default number of values, like 1 or 1024); when the statement has used the whole bunch, another bunch will be reserved, and so on.
That should decrease the contention on the AUTOINC lock in InnoDB while still having statement-based binary logging working.
[28 Aug 2007 20:08] Timothy Smith
Pushed to -target-5.1.22, not fixed in 5.0.
[4 Sep 2007 17:11] Bugs System
Pushed into 5.1.23-beta
[7 Sep 2007 2:20] Paul DuBois
Noted in 5.1.23 changelog.

There is a new innodb_autoinc_lock_mode system variable to configure
the locking behavior that InnoDB uses for generating auto-increment
values. The default behavior now is slightly different from before,
which involves a minor incompatibility for multiple-row inserts that
specify an explicit value for the auto-increment column in some but
not all rows. See:

http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
[5 May 2010 15:07] Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 1:52] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.
[28 May 2010 6:00] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:29] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 6:57] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[29 May 2010 23:59] Paul DuBois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[17 Jun 2010 12:03] Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 12:47] Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:30] Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)