> -----Original Message-----
> From: Jim Starkey [mailto:jstarkey@stripped]
> Sent: Thursday, February 19, 2009 7:55 PM
> To: Vladislav Vaintroub
> Cc: 'Falcon'
> Subject: Re: Index Recovery
> I think we need to find out what is happening. Pages shouldn't get
> lost. If there's a bug, it should be fixed, not papered over.
I think the bug is missing atomic logging of a split.
There are bugs in index logging. I think a least of of them is obvious to me
1. IndexPage::splitPage(). If crash happens and next page is flushed, its
prior pointer points to nowhere. It is not simply fixable with adding
logging to the next page. Newly created page must be logged as well. But if
it is logged, the btree remains inconsistent, because we get an empty page
in the middle of a btree and that breaks the consistency of the btree. Which
leads to rather complicated restructuring of the current code so that next
page is released much later, when the split page is released. Which is no
different from what I propose.
2.Another code in question that looks buggy ( I'm not absolutely sure it is
one, and please correct me if I'm wrong) is at the end of
IndexRootPage::splitIndexPage
splitBdb->mark (transId);
splitPage = (IndexPage*) splitBdb->buffer;
splitPage->parentPage = bdb->pageNumber;
bdb->release(REL_HISTORY);
splitBdb->release(REL_HISTORY);
nice idea , changing the parent page and forgetting to log it.
There could be a bunch of similar errors that are less obvious and the
reason for the bugs is the lack of robust logging strategy. It should not be
possible to modify a page during the split and forget to log it. This is
what I propose.
