> > One issue about too many checkpoints in pg_control, is that you then
> > need to keep more logs, and in my pgbench tests the log space was a
> > real issue, even for the one checkpoint case. I think a utility to
> > recreate a busted pg_control would add a lot more stability, than one
> > more checkpoint in pg_control.
>
> Well, there is a big difference between 1 and 2 checkpoints stored in
> pg_control. I don't intend to go further than 2. But I disagree about
> a log-reset utility being more useful than an extra checkpoint.
Yes I agree, I thought there was already one additional checkpoint info in
pg_control.
> The
> utility would be for manual recovery after a disaster, and it wouldn't
> offer 100% recovery: you couldn't be sure that the last few transactions
> had been applied atomically, ie, all or none. (Perhaps pg_log got
> updated to show them committed, but not all of their tuple changes made
> it to disk; how will you know?) If you can back up to the prior
> checkpoint and then roll forward, you *do* have a shot at guaranteeing
> a consistent database state after loss of the primary checkpoint.
Yes, but a consistent db can only be guaranteed if all txlog logs up to the
crash are eighter rolled forward or at least the physical log pages are written
back to disk.
The consequence is imho, that a good utility to reset the logs should keep
all "physical log" pages, and only clear the log from all other records
[optionally starting at the position that hinders rollforward].
Andreas