"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> "two checkpoints" approach is not the best way to follow.
> From my POV, scanning logs is much better - it doesn't require
> doubling size of on-line logs and allows to *restart* if pg_control
> was lost/corrupted:
> If there is no pg_control or it's corrupted or points to
> unexistent/corrupted checkpoint record then scan logs from
> newest to oldest one till we find last valid checkpoint record
> or oldest valid log record and than redo from there.
And how well will that approach work if the last checkpoint record
got written near the start of a log segment file, and then the
checkpointer discarded all your prior log segments because "you don't
need those anymore"? If the checkpoint record gets corrupted,
you have no readable log at all.
Even if you prefer to scan the logs to find the latest checkpoint
(to which I have no objection), it's still useful for the system
to keep track of the checkpoint-before-latest and only delete log
segments that are older than that.
Of course checkpoint-before-latest is a somewhat arbitrary way of
deciding how far back we need to keep logs, but I think it's more
defensible than anything else we can implement with small work.
> As I explained in short already: with UNDO we'll be able to reuse
> XIDs after restart - ie there will be no point to have NEXTXID
> records at all. And there is no point to add it now.
> Does it fix anything? Isn't "fixing" all what we must do in beta?
If you really insist, I'll take it out again, but I'm unconvinced
that that's necessary.
regards, tom lane