Bug #7973 Index corruption on crash recovery of compact table
Submitted: 17 Jan 2005 22:24 Modified: 25 Jan 2005 11:07
Reporter: Marko Mäkelä Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:5.0.3 OS:Any (all)
Assigned to: Marko Mäkelä CPU Architecture:Any

[17 Jan 2005 22:24] Marko Mäkelä
Description:
There is something wrong in the crash recovery of row_format=compact tables. An assertion failure will be triggered in the page_dir_find_owner_slot() call of page_cur_delete_rec(). This has occurred for a prefix index of a VARCHAR column.

How to repeat:
Set innodb_log_file_size=25M and innodb_buffer_pool_size=10M. Run ibtest16 a bit longer than "round 1200", and then restart the server.

Suggested fix:
Make sure that the dummy index information can be recovered from the redo log properly.
[18 Jan 2005 11:03] Marko Mäkelä
It appears that the redo log entry MLOG_COMP_LIST_END_COPY_CREATED is written or parsed incorrectly.
[18 Jan 2005 15:45] Marko Mäkelä
The bug seems to be in mlog_open_and_write_index(): it should only write n_uniq fields when a non-leaf B-tree page is being updated.
[25 Jan 2005 10:54] Marko Mäkelä
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

InnoDB now writes status bits to MLOG_COMP_REC_INSERT entries.
It is not safe to infer the status bits from the B-tree page
level, because after MLOG_COMP_LIST_END_COPY_CREATED, the
level will not be initialized before the records have been inserted.
[25 Jan 2005 11:07] Marko Mäkelä
There are still problems with the test case that revealed this bug. See Bug #8128.