| Bug #12565 | ERROR 1034 when running simple UPDATE or DELETE on large MyISAM table | ||
|---|---|---|---|
| Submitted: | 13 Aug 2005 6:31 | Modified: | 30 Aug 2005 20:24 |
| Reporter: | Timothy Smith | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: MyISAM storage engine | Severity: | S1 (Critical) |
| Version: | 4.1.14 | OS: | Linux (linux x86) |
| Assigned to: | Ingo Strüwing | CPU Architecture: | Any |
| Tags: | corruption, myisam | ||
[19 Aug 2005 13:42]
Ingo Strüwing
After Bug#6151 and Bug#9188 this was now the third place I had to fix because of the changed end-space comparison behaviour from 4.0 to 4.1.
[23 Aug 2005 15:17]
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/internals/28690
[23 Aug 2005 15:24]
Ingo Strüwing
Thanks Tim. This was very well prepared.
[29 Aug 2005 14:50]
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/internals/28979
[30 Aug 2005 20:24]
Paul DuBois
Noted in 4.1.15, 5.0.12 changelogs.
Description: A large table was supplied by the user. The table has been repaired, and myisamchk --medium shows no errors. When running MySQL 4.1.14, the following UPDATE always results in error 1034: mysql> UPDATE SourcingCandidate SET name = 'Marco Polo', timestampLastUpdate = '1120220851612' WHERE ((id = '102a0a5_f882cde205_-7f7210.0.4.100')); ERROR 1034 (HY000): Incorrect key file for table 'SourcingCandidate'; try to repair it This DELETE also results in the same error, after it runs for a while: DELETE FROM SourcingCandidate where id != '102a0a5_f882cde205_-7f7210.0.4.100'; The UPDATE is easier to test with, because it doesn't affect the .MYD file, so you can just flush tables, copy the good .MYI file over again, and run another test. The customer is using 4.1.8, by the way. The table was repaired on 4.1.13-standard. How to repeat: A copy of the table is on /nfstmp1/tsmith/csc/5012/safe-copy/* There are MD5 sums for the files in .../safe-copy/md5. Put a break point at _mi_ck_real_delete, run, and run the UPDATE query. Step into _mi_fetch_keypage. From what I can tell, _mi_fetch_keypage returns OK, but the next statement run is the goto err inside the if() {...}: (gdb) finish Run till exit from #0 _mi_fetch_keypage (info=0x8b62b38, keyinfo=0x8b61740, page=704553984, level=1024, buff=0x400 <Address 0x400 out of bounds>, return_buffer=1024) at mi_page.c:57 0x082f6332 in _mi_ck_real_delete (info=0x8b62b38, keyinfo=0x8b61740, key=0xadeb60 "", key_length=11394480, root=0x8b62780) at mi_delete.c:154 154 if (!_mi_fetch_keypage(info,keyinfo,old_root,DFLT_INIT_HITS,root_buff,0)) Value returned is $9 = (uchar *) 0xadddb0 "\203�" (gdb) s 157 goto err; I'm not sure why that's happening. Note that I've tested this with a MySQL 4.1 from recent BK, built on 'production' with the BUILD/compile-pentium-debug script. I also got the same results when running on devsrv-a. I'm sorry that I don't have a better test case. The table is huge and hard to work with for that reason, but I don't understand the problem enough to create a better test. Suggested fix: I truly don't know yet what the problem is, or how it might be fixed. I hope Ingo knows. :-)