On Oct23, 2011, at 22:48 , Daniel Farina wrote:
> It doesn't seem meaningful for StartupCLOG (or, indeed, any of the
> hot-standby path functionality) to be called before that code is
> executed, but it is anyway right now.
I think the idea is to check that the CLOG part which recovery *won't*
overwrite is consistent (or rather, given the simplicity of the check,
at least accessible)
Heikki said the following somewhere else in this thread when I suggested
something similar to your proposal:
>> There are pretty clear rules on what state clog can be in. When you launch postmaster in a standby:
>>
>> * Any clog preceding the nextXid from the checkpoint record we start recovery from, must either be valid, or the
clogfile must be missing altogether (which can happen when it was vacuumed away while the backup in progress - if the
clogis still needed at the end of backup it must not be missing, of course).
>> * Any clog following nextXid can be garbled or missing.
>>
>> Recovery will overwrite any clog after nextXid from the WAL, but not the clog before it.
I think Simon's theory that we're starting recovery from the wrong place,
i.e. should start with an earlier WAL location, is probably correct. The
question is, why?
best regards,
Florian Pflug
