> >> * Store two past checkpoint locations, not just one, in pg_control.
> >> On startup, we fall back to the older checkpoint if the newer one
> >> is unreadable.  Also, a physical copy of the newest 
> >> checkpoint record
> 
> > And what to do if older one is unreadable too?
> > (Isn't it like using 2 x CRC32 instead of CRC64 ? -:))
> 
> Then you lose --- but two checkpoints gives you twice the chance of
> recovery (probably more, actually, since it's much more likely that
> the previous checkpoint will have reached disk safely).

This is not correct. If log is corrupted somehow (checkpoint wasn't
flushed as promised) then you have no chance to *recover* because of
DB will be (most likely) in inconsistent state (data pages flushed
before corresponding log records etc). So, second checkpoint gives us
twice the chance to *restart* in normal way - read checkpoint and
rollforward from redo record, - not to *recover*. But this approach
twice increases on-line log size requirements and doesn't help to
handle cases when pg_control was corrupted. Note, I agreed that
disaster *restart* must be implemented, I just think that
"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.

> See later discussion --- Andreas convinced me that flushing NEXTXID
> records to disk isn't really needed after all.  (I didn't 
> take the flush out of my patch yet, but will do so.) I still want
> to leave the NEXTXID records in there, though, because I think that
> XID and OID assignment ought to work as nearly alike as possible.

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?

Vadim

Wed, 7 Mar 2001 18:37:07 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Proposed WAL changes 
"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

Wed, 07 Mar 2001 21:46:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposed WAL changes 