Bug #44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the index (PRIMARY)
Submitted: 2 Apr 2009 5:39 Modified: 18 Jun 2010 23:13
Reporter: Daniel Fiske Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:5.1.33 OS:Any
Assigned to: Satya B CPU Architecture:Any
Tags: experimental
Triage: Triaged: D2 (Serious) / R2 (Low) / E2 (Low)

[2 Apr 2009 5:39] Daniel Fiske
Description:
Started getting the following crash report in error logs

090402  6:25:20  InnoDB: Error: (1500) Couldn't read the MAX(XYZ) autoinc value from the index (PRIMARY).
090402  6:25:20  InnoDB: Assertion failure in thread 2940 in file .\handler\ha_innodb.cc line 2595
InnoDB: Failing assertion: error == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
090402  6:25:20 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=89128960
read_buffer_size=65536
max_used_connections=3
max_threads=100
threads_connected=3
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 119670 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x114cb600
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
006AB35B    mysqld.exe!ha_innobase::open()[ha_innodb.cc:2595]
00443D46    mysqld.exe!handler::ha_open()[handler.cc:2030]
005BD64B    mysqld.exe!open_table_from_share()[table.cc:1881]
00524B47    mysqld.exe!open_unireg_entry()[sql_base.cc:3926]
0052819D    mysqld.exe!open_table()[sql_base.cc:2933]
00529122    mysqld.exe!open_tables()[sql_base.cc:4585]
0052976B    mysqld.exe!open_normal_and_derived_tables()[sql_base.cc:5038]
0059DEEB    mysqld.exe!mysqld_show_create()[sql_show.cc:591]
005542D9    mysqld.exe!mysql_execute_command()[sql_parse.cc:2880]
7C9105C8    ntdll.dll!RtlFreeHeap()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 114EA420=show create table `XYZ`.`ABC`
thd->thread_id=3
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
Unfortunately can't actively reproduce how it gets into this state. Behaviour repeats until table is dropped and recreated.

Suggested fix:
Unknown.
[2 Apr 2009 6:48] Valeriy Kravchuk
Do you know if this table is from older version of MySQL or created with InnoDB Plugin maybe?
[2 Apr 2009 9:38] Daniel Fiske
Made a mistake on what version it was (not 5.1.33, but rather 5.1.32)

It certainly has migrated through the versions as it it part of a test environment...probably as early as 5.0.4x. I do suspect some possible data corruption in the innodb data file. I've exported (mysqldump) what I could get out of the old database and restored it to a clean 5.1.33. Will see if issue has resolved after this.

Will close this bug for now.
[3 Apr 2009 13:04] Daniel Fiske
Created a fresh 5.1.33 install. Created tables from scratch. Error appeared again, but hadn't enabled the general log to get exact sequence to reproduce. Will continue to try and produce a test case.
[3 Apr 2009 13:54] Valeriy Kravchuk
It would be nice to see a test case for fresh 5.1.33.
[3 Apr 2009 17:20] Teste Silva
Hi,

Maybe I am wrong but if you look at ha_innodb.cc in 5.1.32 line 2595:

error = innobase_initialize_autoinc();
/* Should always succeed! */
ut_a(error == DB_SUCCESS);

But innobase_initialize_autoinc may return an error:

        } else {
                ut_print_timestamp(stderr);
                fprintf(stderr, "  InnoDB: Error: (%lu) Couldn't read "
                        "the MAX(%s) autoinc value from the "
                        "index (%s).\n", error, col_name, index->name);
        }

I have noticed that in 5.1.30 I got the above error message with some tables, now with 5.1.32 I got a server crash when using the same tables.
[29 Apr 2009 23:45] Miguel Solorzano
Bug: http://bugs.mysql.com/bug.php?id=44555 marked as duplicate of this one.
[30 Apr 2009 7:53] Sveta Smirnova
Thank you for the feedback.

Set to "Verified", because bug #44555 contains corrupted data directory.

To repeat this error:

1. Download, then unrar data from bug #44555
2. Start mysqld like 

./libexec/mysqld --defaults-file=support-files/my-small.cnf --basedir=. --datadir=/Users/apple/Documents/web_project/MySQL/bugs/bug44555 --innodb_log_file_size=25165824 --log-error --socket=/tmp/mysql5111.sock --port=335111 --skip-grant-tables 

3. Connect to mysqld, then run USE dbname

innodb_force_recovery=6 doesn't help
[30 Apr 2009 14:59] Mikhail Izioumtchenko
assigning, but a few things would be nice: 
1. a test case, of course
2. which version of MySQL the database was created with
3. are there any occurrences outside of Windows?
[1 May 2009 7:21] Sunny Bains
Hi,

Unable to reproduce the error using the data file data.part001.rar. The
data files need to be fixed. All the files were dumped in the same directory.
The subdirs myob and mysql were missing, had to create them manually and copy
the files, I used the following command to uncompress:

    unrar e -r filename.rar

data.part001.rar:

USE myob;
SELECT COUNT(*) FROM each table in myob and there was no crash reported.

No problems

data.part002.rar:
USE myob;
SELECT COUNT(*) FROM testdatatype; -- caused the assertion failure

Cause of failure is that the InnoDB data dictionary is either corrupt because
the autoincrement column name in the InnoDB data dictionary is "_id" whereas
in the MySQL data dictionary it's "id". If it's not corrupt then someone has
probably recreated the table in MySQL and copied the InnoDB files from another
installation (best guess).

Currently if InnoDB can't find the autoinc column name, it's reported as
DB_RECORD_NOT_FOUND (1500) because we resuse an existing error code. The lookup
currently is not expected to fail ie. it's deemed an invariant. The question
now is that should this be changed to a different error code such as DB_CORRUPT
and the error code percolated back up to MySQL so that the table is deemed
unusable by MySQL with the side effect that the database doesn't crash anymore.

Regards,
-sunny
[2 May 2009 16:08] Stephane Bakhos
I've hit the same bug on Linux with Gentoo.
Mysql Community 5.1.34
Upgraded from Mysql Community 5.1.28

3 tables with InnoDb are dead (there were all 3 on the server)

090502 11:25:42  InnoDB: Error: (1500) Couldn't read the max AUTOINC value from the index (PRIMARY).
090502 11:25:42  InnoDB: Error: (1500) Couldn't read the max AUTOINC value from the index (PRIMARY).
090502 11:25:42 [ERROR] Cannot get table dev2/Inventaire auto-inccounter value in ::info

090502 11:25:42  InnoDB: Error: (1500) Couldn't read the max AUTOINC value from the index (PRIMARY).
090502 11:25:42  InnoDB: Error: (1500) Couldn't read the max AUTOINC value from the index (PRIMARY).
090502 11:25:42 [ERROR] Cannot get table dev2/Inventaire_Champs auto-inccounter value in ::info

Then on any kind of access:
090502 11:37:06  InnoDB: Error: (1500) Couldn't read the MAX(inventaire_id) autoinc value from the index (PRIMARY).
090502 11:37:06  InnoDB: Assertion failure in thread 140297915251024 in file handler/ha_innodb.cc line 2601
InnoDB: Failing assertion: error == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
090502 11:37:06 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133887 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x1c6f550
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f99a766b0f0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x29) [0x84f7a9]
/usr/sbin/mysqld(handle_segfault+0x383) [0x5d3e03]
/lib/libpthread.so.0 [0x7f99a73ab390]
/lib/libc.so.6(gsignal+0x35) [0x7f99a62925c5]
/lib/libc.so.6(abort+0x110) [0x7f99a6293a70]
/usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int)+0x30f) [0x73383f]
/usr/sbin/mysqld(handler::ha_open(st_table*, char const*, int, int)+0x3f) [0x6a72cf]
/usr/sbin/mysqld(open_table_from_share(THD*, st_table_share*, char const*, unsigned int, unsigned int, unsigned int, st_table*, bool)+0x55f) [0x61f0cf]
/usr/sbin/mysqld [0x617eed]
/usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, st_mem_root*, bool*, unsigned int)+0x79e) [0x61a34e]
/usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int)+0x5d2) [0x61aed2]
/usr/sbin/mysqld(open_and_lock_tables_derived(THD*, TABLE_LIST*, bool)+0x62) [0x61b0b2]
/usr/sbin/mysqld [0x6b9ae1]
/usr/sbin/mysqld(mysql_check_table(THD*, TABLE_LIST*, st_ha_check_opt*)+0x60) [0x6ba8c0]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x234f) [0x5e087f]
/usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x211) [0x5e3e91]
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xb8f) [0x5e5caf]
/usr/sbin/mysqld(do_command(THD*)+0xe8) [0x5e6588]
/usr/sbin/mysqld(handle_one_connection+0x226) [0x5d9fe6]
/lib/libpthread.so.0 [0x7f99a73a3067]
/lib/libc.so.6(clone+0x6d) [0x7f99a63273ed]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x1cdbee0 = CHECK TABLE `Inventaire`  FOR UPGRADE
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
090502 11:37:31  InnoDB: Database was not shut down normally!

I can attach the .frm files, but not the innodb data because of legal restrictions.
[3 May 2009 9:18] Sveta Smirnova
Sunny,

please use both rar files: archive was split in 2 files. If use both files every database needed exists.
[8 May 2009 6:36] Sveta Smirnova
Daniel,

have you moved the InnoDB files from elsewhere and recreated the table in
MySQL?
[18 May 2009 0:11] Sunny Bains
>What we need here is:

>* Better error message, indicating that table data and table definition (in >InnoDB datadictionary) differ.

This can be done.

> * InnoDB should refuse to use that table and will return error on any access 
> * Error message should advise customer / user to repair table, by forced recovery, dump /restore

Another option I was thinking about was to set the autoinc counter to the MAX_VALUE on error. That way the table can be accessed but attempts to write
to it will fail. The column value is only required to read the max(column) value on open. Secondly, the user also has the option of using DDL to set the
autoinc value and/or dump the data.

Regards,
-sunny
[18 May 2009 12:54] Sinisa Milivojevic
Sunny,

I fully agree.

Please set E/R values accordingly.

Thanks in advance.
[25 May 2009 5:17] Sveta Smirnova
Bug #45009 looks like duplicate of this one.
[1 Jun 2009 12:20] Marko Mäkelä
There seems to be a common root cause between Bug #44030, Bug #44571, and Bug #45124: MySQL is renaming columns without telling InnoDB (“smart” ALTER TABLE). Fix: MySQL should either communicate column renames to the storage engine or copy InnoDB tables when columns are renamed.
[4 Jun 2009 9:37] Frederic De Pauw
Hello,

I have the same problem with my database. I am using "Mysql Query Browser" to create and update my tables.

090604 11:22:46  InnoDB: Error: (1500) Couldn't read the MAX(Cli__IDClient) autoinc value from the index (PRIMARY).
090604 11:22:46  InnoDB: Assertion failure in thread 632 in file .\handler\ha_innodb.cc line 2601
InnoDB: Failing assertion: error == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
090604 11:22:46 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=26214400
read_buffer_size=65536
max_used_connections=3
max_threads=100
threads_connected=3
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 58231 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x6c20680
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
006ADC0B    mysqld.exe!ha_innobase::open()[ha_innodb.cc:2601]
00443C06    mysqld.exe!handler::ha_open()[handler.cc:2037]
005BF63B    mysqld.exe!open_table_from_share()[table.cc:1882]
00525EF7    mysqld.exe!open_unireg_entry()[sql_base.cc:3927]
0052954D    mysqld.exe!open_table()[sql_base.cc:2934]
0052A4D2    mysqld.exe!open_tables()[sql_base.cc:4586]
0052AB1B    mysqld.exe!open_normal_and_derived_tables()[sql_base.cc:5039]
00591096    mysqld.exe!fill_schema_show_cols_or_idxs()[sql_show.cc:2929]
0059CF21    mysqld.exe!get_all_tables()[sql_show.cc:3221]
00526DDE    mysqld.exe!find_field_in_tables()[sql_base.cc:6344]
00589108    mysqld.exe!remove_const()[sql_select.cc:7000]
0058E98F    mysqld.exe!JOIN::exec()[sql_select.cc:1649]
0058FFA3    mysqld.exe!mysql_select()[sql_select.cc:2380]
005903DB    mysqld.exe!handle_select()[sql_select.cc:268]
005539B4    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4982]
00554AF6    mysqld.exe!mysql_execute_command()[sql_parse.cc:2204]
0055A133    mysqld.exe!mysql_parse()[sql_parse.cc:5906]
0055AC23    mysqld.exe!dispatch_command()[sql_parse.cc:1218]
0055BA27    mysqld.exe!do_command()[sql_parse.cc:861]
005DEC81    mysqld.exe!handle_one_connection()[sql_connect.cc:1115]
00644D1B    mysqld.exe!pthread_start()[my_winthread.c:85]
0072A1A3    mysqld.exe!_callthreadstart()[thread.c:293]
FC8FE900    
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 02D3C3E8=describe client
thd->thread_id=3
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
InnoDB: Thread 2724 stopped in file .\os\os0sync.c line 574
InnoDB: Thread 5288 stopped in file .\os\os0sync.c line 271
InnoDB: Thread 5996 stopped in file .\os\os0sync.c line 574
[4 Jun 2009 9:41] Sunny Bains
Committed in r5243:

When the InnoDB and MySQL data dictionaries get out of sync, before the bug fix we would assert on missing autoinc columns. With this fix we allow MySQL to open the table but set the next autoinc value for the column to the MAX value. This effectively disables the next value generation. INSERTs will fail with a generic AUTOINC failure. However, the user should be able to read/dump the table, set the column values explicitly, use ALTER TABLE to set the next autoinc value and/or sync the two data dictionaries to resume normal operations.
[16 Jun 2009 15:18] Samuel Sol Santos
I'm hitting this bug recently too. Table created from scratch on Mysql 5.1.33 Community on an XAMPP installing on a Windows XP SP3 (32-bit) machine. Table stopped worked out of the blue, and can't issue any command to it. ANALYZE, CHECK, everything crashes the server. The error message is the same as the others and is at the bottom of the post. 

Question is, what can I do now to salvage the data and allow the server to continue while this patch doesn't hit us.

090616 12:10:05  InnoDB: Error: (1500) Couldn't read the MAX(id_inadimplencia) autoinc value from the index (PRIMARY).
090616 12:10:05  InnoDB: Assertion failure in thread 3556 in file .\handler\ha_innodb.cc line 2601
InnoDB: Failing assertion: error == DB_SUCCESS
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
090616 12:10:05 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=20971520
read_buffer_size=262144
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 137400 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x5760ee8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
006AC8BB    mysqld.exe!???
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0C3CD3E8=analyze table base
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
InnoDB: Thread 3148 stopped in file .\os\os0sync.c line 271
InnoDB: Thread 3460 stopped in file .\os\os0sync.c line 574
[22 Jun 2009 15:21] Daniel Fiske
Although I haven't tested the fix, I'm not convinced

"Committed in r5243:

When the InnoDB and MySQL data dictionaries get out of sync, before the bug fix we would assert on missing autoinc columns. With this fix we allow MySQL to open the table but set the next autoinc value for the column to the MAX value. This effectively disables the nextvalue generation. INSERTs will fail with a generic AUTOINC failure. However, the user should be able to read/dump the table, set the column values explicitly, use ALTER TABLE to set the next autoinc value and/or sync the two data dictionaries to resume normal
operations."

Surely the issue has become "When the InnoDB and MySQL data dictionaries get out of sync" not how it is being handled? I'm going to venture that there is another bug that has been introduced in the 5.1.x branch that is causing the "out of sync" issue, which hasn't really been reported on the 5.0.x branch.
[25 Jul 2009 10:26] Philip S
I had the same issue.  I tried upgrading from 5.1.33 to 5.1.36, but mysqld would still crash whenever accessing the database.  

Some details, most of it probably irrelevant, but maybe something will pop out:
This is a brand new laptop, and I just started on a new project.
MD Turion X2 Dual-Core Mobile RM-74 w/4GB RAM
DB size on disk is 1.67GB
1GB of RAM is being used as a ramdisk
Fresh install of 5.1.33 on MS Vista 64 using the WAMP project installer.
A lot of ALTERs, as this is a dev environment.  Adding columns, indexes, etc.  Renaming columns as well.  
The bug cropped up between coding sessions rather than during a coding session.
All db schema was created using MySQL Administrator, and all data manipulation done using php and mysqli.  
Everything wrt MySQL is brand new.
I'm sorry, I'm unable to provide data files.

Anyway, as the upgrade didn't work to allow me to access the data, and a lot of work occurred since my last backup, I wanted to restore/retrieve as much of the DB schema as possible, I wasn't concerned with data.  I actually did retrieve most of the data as well.  While I'm sure the process can be optimized, what worked for me is:
C:\wamp\bin\mysql\mysql5.1.36\bin>mysqlshow.exe -u root <dbname>
then for each table
C:\wamp\bin\mysql\mysql5.1.36\bin>mysqlshow.exe -u root <dbname> <table>
until I got the error 
mysqlshow.exe: Cannot list columns in db: <dbname>, table: <table>: Lost connection to MySQL server during query
then I restarted mysqld, started the MySQL console, and
\u <dbname>
drop table <table>
for the table which caused the crash.  After that, everything was back to normal other than the loss of the one small table which I should be able to recreate easily.
[13 Aug 2009 20:04] Sveta Smirnova
Bug #46699 was marked as duplicate of this one.
[13 Aug 2009 22:28] Javier Sanchez
I tried to delete the table that was causing the error following Philip S instructions, but it seems that mysql do nothing and i still cannot access to the database without getting mysql error.
[15 Aug 2009 5:36] Philip S
Javier Sanchez, what happens when you try?  Does the table not get dropped?  Do other tables have the same error?  Does every table have the same error?  Does the error appear again when you recreate the table from scratch?  

To clarify the last step:
C:\wamp\bin\mysql\mysql5.1.36\bin>net start MySQL
C:\wamp\bin\mysql\mysql5.1.36\bin>mysql.exe -u root
mysql>\u <dbname>;
Database changed
mysql>drop table <table>;
[4 Sep 2009 7:54] Engin Vardar
Philip's instructions did the trick for me. when you drop the table everything goes back to normal.
[17 Sep 2009 6:30] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/83551

3110 Satya B	2009-09-17
      Applying InnoDB snapshot 5.1-ss5282, Fixes BUG#44030
      
      1. Fixes BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc value 
                           from the index (PRIMARY)
      
      2. Disables the innodb-autoinc test for innodb plugin temporarily.
         The testcase for this bug has different result file for InnoDB plugin.
         Should add the testcase to Innodb suite with a different result file.
      
      Detailed revision comments:
      
      r5243 | sunny | 2009-06-04 03:17:14 +0300 (Thu, 04 Jun 2009) | 14 lines
      branches/5.1: When the InnoDB and MySQL data dictionaries go out of sync, before
      the bug fix we would assert on missing autoinc columns. With this fix we allow
      MySQL to open the table but set the next autoinc value for the column to the
      MAX value. This effectively disables the next value generation. INSERTs will
      fail with a generic AUTOINC failure. However, the user should be able to
      read/dump the table, set the column values explicitly, use ALTER TABLE to
      set the next autoinc value and/or sync the two data dictionaries to resume
      normal operations.
      
      Fix Bug#44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the
      index (PRIMARY)
      
      rb://118
      
      r5252 | sunny | 2009-06-04 10:16:24 +0300 (Thu, 04 Jun 2009) | 2 lines
      branches/5.1: The version of the result file checked in was broken in r5243.
      
      r5259 | vasil | 2009-06-05 10:29:16 +0300 (Fri, 05 Jun 2009) | 7 lines
      branches/5.1:
      
      Remove the word "Error" from the printout because the mysqltest suite
      interprets it as an error and thus the innodb-autoinc test fails.
      
      Approved by:	Sunny (via IM)
      r5466 | vasil | 2009-07-02 10:46:45 +0300 (Thu, 02 Jul 2009) | 6 lines
      branches/5.1:
      
      Adjust the failing innodb-autoinc test to conform to the latest behavior
      of the MySQL code. The idea and the comment in innodb-autoinc.test come
      from Sunny.
[18 Sep 2009 6:52] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/83675

2881 Alexander Nozdrin	2009-09-18 [merge]
      Null-merge 5.1-bugteam revno:3110 (fix for Bug#44030).
      After discussion with Satya this bug does not exist
      in trunk.
[18 Sep 2009 7:03] Satya B
Small correction: In 5.4, the bug has been already fixed.
[23 Sep 2009 12:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/84339

3123 Satya B	2009-09-23
      Additional Fix for BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc 
                                     value from the index (PRIMARY)
      
      
      With the fix for BUG#46760, we correctly flag the presence of row_type 
      only when it's actually changed and enables the FAST ALTER TABLE which was
      disabled with the BUG#39200.
      
      So the changes made by BUG#46760 makes MySQL data dictionaries to be out of 
      sync but they are handled already by InnoDB with this BUG#44030.
      
      The test was originally written to handle this but we requested Innodb to
      update the test as the data dictionaries were in sync after the fix for 
      BUG#39200.
      
      Adjusting the innodb-autoinc testcase as mentioned in the comments.
     @ mysql-test/lib/mtr_cases.pm
        Re-enable the innodb-autoinc test case for plugin as we have a common
        result file.
     @ mysql-test/r/innodb-autoinc.result
        Additional Fix for BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc 
                                       value from the index (PRIMARY)
        
        Adjust the innodb-autoinc testcase as the patch for BUG#46760 enables the 
        FAST ALTER TABLE and makes the data dictonaries go out of sync. This is 
        expected in the testcase.
     @ mysql-test/t/innodb-autoinc.test
        Additional Fix for BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc 
                                       value from the index (PRIMARY)
        
        Adjust the innodb-autoinc testcase as the patch for BUG#46760 enables the 
        FAST ALTER TABLE and makes the data dictonaries go out of sync. This is 
        expected in the testcase.
[30 Sep 2009 8:17] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20090929093622-1mooerbh12e97zux) (version source revid:alik@sun.com-20090922182109-vs5ign07cwht12z6) (merge vers: 6.0.14-alpha) (pib:11)
[30 Sep 2009 8:20] Bugs System
Pushed into 5.4.5-beta (revid:alik@sun.com-20090925094254-tjl9eajkzwzgthoe) (version source revid:alik@sun.com-20090918152344-nl5pzeugpejb2sth) (merge vers: 5.4.3-beta) (pib:11)
[6 Oct 2009 9:00] Bugs System
Pushed into 5.1.40 (revid:joro@sun.com-20091006073316-lea2cpijh9r6on7c) (version source revid:satya.bn@sun.com-20090923121212-4x70dbou02bbq88k) (merge vers: 5.1.40) (pib:11)
[8 Oct 2009 13:01] Database Administrator
Hi,

I am also having the same problem and tried the trick instructed by Philip, but not able to drop/alter the table. If I try to do so the server started to crash.
Please help urgent!!!
[14 Oct 2009 10:04] Satya B
Paul,

This bug is fixed in 5.1 & 5.4 and Null merged to 6.0
[14 Oct 2009 15:56] Paul Dubois
Noted in 5.1.40, 5.4.2 changelogs.

InnoDB use of SELECT MAX(autoinc_column) could cause a crash when
MySQL data dictionaries went out of sync.
[22 Oct 2009 6:33] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)
[22 Oct 2009 7:05] Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091013094238-g67x6tgdm9a7uik0) (merge vers: 5.5.0-beta) (pib:13)
[22 Oct 2009 20:05] Paul Dubois
Noted in 5.5.0 changelog. (Null merge to 6.0)
[18 Dec 2009 10:26] Bugs System
Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)
[18 Dec 2009 10:43] Bugs System
Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)
[18 Dec 2009 10:58] Bugs System
Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)
[18 Dec 2009 11:12] Bugs System
Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)
[4 Feb 2010 10:19] Bugs System
Pushed into 5.1.44 (revid:joro@sun.com-20100204101444-2j32mhqroo0iiio6) (version source revid:dao-gang.qu@sun.com-20100125025505-zqa9v2mgdcfza0v6) (merge vers: 5.1.43) (pib:16)
[5 Feb 2010 11:49] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100204063540-9czpdmpixi3iw2yb) (version source revid:alik@sun.com-20100130201057-zm9nj1sy0xpz1ohp) (pib:16)
[5 Feb 2010 11:55] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100205113942-oqovjy0eoqbarn7i) (version source revid:alik@sun.com-20100204064210-ljwanqvrjs83s1gq) (merge vers: 6.0.14-alpha) (pib:16)
[5 Feb 2010 12:00] Bugs System
Pushed into 5.5.2-m2 (revid:alik@sun.com-20100203172258-1n5dsotny40yufxw) (version source revid:alik@sun.com-20100130182921-uva9w0cxpxqeylbf) (merge vers: 5.5.2-m2) (pib:16)
[5 Feb 2010 16:52] Paul Dubois
Setting report to Need Merge pending push to Celosia.
[12 Mar 2010 14:07] Bugs System
Pushed into 5.1.44-ndb-7.0.14 (revid:jonas@mysql.com-20100312135944-t0z8s1da2orvl66x) (version source revid:jonas@mysql.com-20100312115609-woou0te4a6s4ae9y) (merge vers: 5.1.44-ndb-7.0.14) (pib:16)
[12 Mar 2010 14:23] Bugs System
Pushed into 5.1.44-ndb-6.2.19 (revid:jonas@mysql.com-20100312134846-tuqhd9w3tv4xgl3d) (version source revid:jonas@mysql.com-20100312060623-mx6407w2vx76h3by) (merge vers: 5.1.44-ndb-6.2.19) (pib:16)
[12 Mar 2010 14:37] Bugs System
Pushed into 5.1.44-ndb-6.3.33 (revid:jonas@mysql.com-20100312135724-xcw8vw2lu3mijrhn) (version source revid:jonas@mysql.com-20100312103652-snkltsd197l7q2yg) (merge vers: 5.1.44-ndb-6.3.33) (pib:16)
[12 Mar 2010 17:42] Paul Dubois
Fixed in earlier 5.1.x, 5.5.x.
[6 Apr 2010 7:56] Bugs System
Pushed into 5.1.46 (revid:sergey.glukhov@sun.com-20100405111026-7kz1p8qlzglqgfmu) (version source revid:svoj@sun.com-20100401151005-c6re90vdvutln15d) (merge vers: 5.1.46) (pib:16)
[6 Apr 2010 11:53] Jon Stephens
Already documented. Closed.
[5 May 2010 15:04] 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 17:53] Paul Dubois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[28 May 2010 6:06] 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:34] 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 7:02] 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 15:24] Paul Dubois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[15 Jun 2010 8:08] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)
[15 Jun 2010 8:24] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[17 Jun 2010 12:10] 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:58] 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:38] 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)