List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:February 19 2009 3:14am
Subject:Re: 2 recovery bugs, single patch, please check
View as plain text  
Kevin Lewis wrote:
> > Vladislav Vaintroub wrote:
>> General question unrelated to the patch mostly to Kevin and Chris : 
>> should
>> background activities scavenger/updateCardinalities be disabled for the
>> whole duration of recovery or for phase1 and 2 of recovery? I was 
>> somewhat
>> surprised seeing interference with background threads there, because 
>> I was
>> somehow sure recovery runs alne. I do not think recovery was written 
>> with
>> concurrency in mind. Was scavenger meant to run in recovery at all?  
>> Does
>> updateCardinality make sense? Any thoughts? 
> It appears that recovery does not build up the record cache.  So there 
> is no reason to run the scavenger during recovery.  You can disable 
> the scheduled version of the scavenger during recovery.  The 
> load-based version should not be activated since there are no calls to 
> allocRecord() or allocRecordVersion().  But if I missed something, and 
> the record cache does fill up during recovery, then you do want the 
> scavenger to run.  Maybe not all of it.  But prune and retire should run.
Very little of the Falcon engine is up and running during recovery.  In 
specific, the general table walking code is not yet functional.  To be 
able to process a logical record, it is necessary to do a table lookup 
to find the format to interpret the physical record.  The "bootstrap" 
code that reads the system.tablespaces table is a major end run.  The 
bootstrap code knows the section id from the header page and has the 
logical format of the system.tablespaces hard coded.

The various background threads should not be active until after 
recovery, with the possible exception of the so-called I/O threads.

The scavenger should not start until after recovery.

And, no, recovery was most certainly not intended to operate with 
concurrency in mind.
2 recovery bugs, single patch,please check Vaintroub18 Feb
  • Re: 2 recovery bugs, single patch,please check Lewis19 Feb
    • Re: 2 recovery bugs, single patch, please check Starkey19 Feb