MySQL Bugs: #44542: Falcon needs a redesign of IndexRootPage::addIndexEntry

Bug #44542	Falcon needs a redesign of IndexRootPage::addIndexEntry
Submitted:	29 Apr 2009 14:29	Modified:	26 May 2010 17:53
Reporter:	Kevin Lewis	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0.11	OS:	Any
Assigned to:	Lars-Erik BjÃ¸rk	CPU Architecture:	Any
Tags:	F_INDEX

Description:
Vlad has implemented a temporary solution for Bug#37056 which avoids the assert by increasing the loop count to 1000 instead of 10.  This solution seems to effectively reduce the occurrence of this bug so that it is not currently seen.

What is left is probably not a Beta bug, so that BETA bug is closed and this bug is opened to track a better fix.  

Vlad has proposed a better patch here; 
   http://lists.mysql.com/commits/72043

But he sees other crashes with this change during normal testing.  So the patch above needs a little work.

How to repeat:
The assert at the bottom of IndexRootPage::addIndexEntry is not currently being hit.  But only because the loop count is now 1000.

Suggested fix:
Improve this patch; http://lists.mysql.com/commits/72043.

This crash has now been seen also after the loop count was increased from 10 to 1000. This happened when running the falcon_pagesize32K test (note earlier it used to happen for the falcon_pagesize2K test, I think). The error message in the log file:

[Falcon] Error: assertion (false) failed at line 213 in file IndexRootPage.cpp

In Bug#46083 this crash is seen during recovery. This might indicate that this is not a concurrency issue since recovery is done mostly by a single thread. The bug is reproducable using the database and log files from the crash reported in Bug#46083.

Lars-Erik,  Could you take a look at Vlads patch once again in light of your recent changes for Bug#46083.  Maybe you will/have discover why that patch did not work.

If the assert in IndexRootPage::addIndexEntry does not happen after the patch for bug#46083, this bug may be closed