| 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: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 5.1.33 | OS: | Any |
| Assigned to: | Satya B | CPU Architecture: | Any |
| Tags: | experimental | ||
[2 Apr 2009 5:39]
Daniel Fiske
[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]
MySQL Verification Team
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]
MySQL Verification Team
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)
