MySQL Bugs: #6222: false errors with myisamchk's extended repair

Bug #6222	false errors with myisamchk's extended repair
Submitted:	22 Oct 2004 21:16	Modified:	24 Oct 2004 23:07
Reporter:	Matthew Lord	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S2 (Serious)
Version:	all	OS:	Any (all)
Assigned to:	Sergei Golubchik	CPU Architecture:	Any

Description:
check table foo extended; /* OK */
myisamchk -c -e foo /* OK */
myisamchk -r foo /* OK */

myisamchk -r -e foo /* reports an error */

How to repeat:
Run the above commands on the attached table.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.mysql.com/documentation/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Additional info:

As written in the manual:

`--extend-check, -e'
     Do a repair that tries to to recover every possible row from the
     data file.  Normally this will also find a lot of garbage rows.
     Don't use this option unless you are totally desperate.

It is expected that myisamchk -r -e can report errors in these garbage rows.

Sergei,

Are you trying to say that most tables have "garbage" rows?  A garbage row
just being a row marked as deleted?  This does not seem to be the case with
the attached table as it has no rows marked as deleted and optimize table
does nothing.

Can you elaborate on why this is not a bug?

Best Regards

"Garbage row" is not a deleted row, it's just a row that shouldn't be in the table, the one that contains garbage.

myisamchk in "extended repair" mode assumes that the table is badly damaged, it no longer trusts record (block) headers, and does not believe that next record starts in the file where the previous ends. Instead it searches for block headers everywhere (!) in the MYD file. And it is quite possible that block header signature is present somewhere in the row data - then myisamchk will try to recover a block that starts from this "block header". And myisamchk will report an error if it will not work (and it most probably will not, as such a spurious header will most probably contain very weird offset values, pointers, and sizes). That's where spurious rows or spurious errors come from.

Indeed, the manual says "Don't use this option unless you are totally desperate" - and not without a reason.