MySQL Bugs: #8269: myisamchk reports corruption on fresh imported table

Bug #8269	myisamchk reports corruption on fresh imported table
Submitted:	2 Feb 2005 15:56	Modified:	28 Jul 2005 12:31
Reporter:	Roberto Bourgonjen	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S1 (Critical)
Version:	4.1.9	OS:	Linux (Redhat EL 3 Update 4)
Assigned to:	Ingo Strüwing	CPU Architecture:	Any

Description:
After migrating from 3.23.58 to 4.1.9, many tables were indicated being corrupted. All tables were indicated ok on 3.23.58. I have fixed them succesfully using myisamchk 4.1.9 (some with -r, but some needed -o), but after a while, some were being reported as corrupted again. Some tables I could then not even repair with myisamchk -r or -o, but then the myisamchk that came with version 3.23.58 _could_ fix them, after which however, myisamchk 4.1.9 still complained about "Can't find key for index: x" when using myisamchk -c -e.

I had this problem on some very large tables, with millions of records, but also on smaller ones, with only a couple of thousands.

How to repeat:
For one database I then tried to create the database in 4.1.9 from scratch, and import the data from a dump file. Even then, myisamchk complained about table corruption!

Here's how to reproduce:

Consider the dump file at:
ftp://gaa.nl/pub/mysqldump.sql.gz (122Mb)

after gunzipping the dump, import the database (5 million records):
mysql test < mysqldump.sql

shutdown mysql, and check the table:
myisamchk -c Url.MYI
on my system it reports: "Key in wrong position at page 169219072."

myisamchk -c -e Url.MYI
will also complain "Record at:      69452  Can't find key for index:  3"

After repairing with
myisamchk -r Url.MYI
the problem remains, both when checking with -c and -c -e

myisamchk -o Url.MYI
seems to fix this

Hello Roberto. I'm experiencing the same issue with a similarly spec'd server. RHEL, moving from 3.23.58 to 4.1.9, and getting the same symptoms (check table / myisamchk reports fixed, but it 'breaks' again a few days later). I'm not terribly experienced, so pardon if the following speculation is totally outlandish. 

I noticed when I did a phpinfo() that the mysql client API is still being reported as 3.23.58. I wasn't aware that I would have to recompile PHP to take the new changes into effect. Is it possible that this discrepancy between API's could be causing this issue?

Any progress on this bug?

Same problem on Redhat EL 4, with the with this release included mysql version 4.1.7

All five commands work for me on 4.1.13.
This has probably been fixed in 4.1.12 together with bug #9188.