List:Falcon Storage Engine« Previous MessageNext Message »
From:Vladislav Vaintroub Date:February 19 2009 8:54pm
Subject:RE: Index Recovery
View as plain text  

> -----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?


> Jim Starkey
> President, NimbusDB, Inc.
> 978 526-1376
> 
> 
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe:    http://lists.mysql.com/falcon?unsub=1


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