MySQL Bugs: #7973: Index corruption on crash recovery of compact table

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

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.

It appears that the redo log entry MLOG_COMP_LIST_END_COPY_CREATED is written or parsed incorrectly.

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.

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.

There are still problems with the test case that revealed this bug. See Bug #8128.