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.
