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 clog file must be missing >> altogether (which can happen when it was vacuumed away while the backup in >> progress - if the clog is 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
