List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:February 19 2009 9:45pm
Subject:Re: Index Recovery
View as plain text  
Vladislav Vaintroub wrote:
>   
>> -----Original Message-----
>> From: Jim Starkey [mailto:jstarkey@stripped]
>> Sent: Thursday, February 19, 2009 9:13 PM
>> To: Vladislav Vaintroub
>> Cc: 'Falcon'
>> Subject: Re: Index Recovery
>>     
>>> 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.
>>>
>>>
>>>
>>>
>>>       
>> I don't think that is a bug.  An attempted insertion forced a split.
>> This is a retry have the split was complete.  The node insertion would
>> have already need logged.
>>     
>
>
> I have to admit, I have not got the idea. Why changing parent pointer or a
> page and not logging this fact is not a bug?
>
> In the serial log ,the parent will be wrong? Recovery, in redoIndexPage I
> will read and modify this wrong parent and insert the first key and page
> number?
>
>   
This is a case where a comment would be in order.  The line in question 
is actually a no-op.

Normally, a parent never changes.  An exception is when a new level is 
created.  The original root page stays the root pages and some fancy 
switching takes places that changes the parents.

In the bad old days, the parent pointer was purely for 
documentation/consistency.  And, lo and behold, like anything that is 
set but not checked, it wasn't being properly handled.  So the bug got 
fixed and the parent page number was correct.  To fix existing databases 
where the parent page was flaky, I put in this back to force it to the 
right value.

That line of code should be replaced with ASSERTION that the parent page 
number is correct (if I made one mistake, I probably made at least two).

But no, I don't thank that is a bug.  The correct parent page number was 
correct set during the page split and has already need correctly logged.

But nice catch on an obscure piece of code.




-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Thread
[Fwd: Index Discussion]Kevin Lewis19 Feb
  • Re: [Fwd: Index Discussion]Ann W. Harrison19 Feb
    • Index RecoveryVladislav Vaintroub19 Feb
      • RE: Index RecoveryVladislav Vaintroub19 Feb
      • Re: Index RecoveryJim Starkey19 Feb
        • RE: Index RecoveryVladislav Vaintroub19 Feb
          • Re: Index RecoveryJim Starkey19 Feb
            • RE: Index RecoveryVladislav Vaintroub19 Feb
              • Re: Index RecoveryJim Starkey19 Feb