On Mon, 2006-08-07 at 13:05 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've implemented this for BTree, GIN, GIST using an additional rmgr
> > function bool rm_safe_restartpoint(void)
> > ...
> > "Recovery checkpoints" are now renamed "restartpoints" to avoid
> > confusion with checkpoints. So checkpoints occur during normal
> > processing (only) and restartpoints occur during recovery (only).
> Applied with revisions.
err....CheckPointGuts() :-) I guess patch reviews need some spicing up.
> As submitted the patch pushed backup_label out
> of the way immediately upon reading it, which is no good: you need to be
> sure that the starting checkpoint location is written to pg_control
> first, else an immediate crash would allow the thing to try to start
> from whatever checkpoint is listed in the backed-up pg_control. Also,
> the minimum recovery stopping point that's obtained using the label file
> still has to be enforced if there's a crash during the replay sequence.
> I felt the best way to do that was to copy the minimum stopping point
> into pg_control, so that's what the code does now.
Thanks for checking that.
> Also, as I mentioned earlier, I think that doing restartpoints on the
> basis of elapsed time is simpler and more useful than having an explicit
> distinction between "normal" and "standby" modes. We can always invent
> a standby_mode flag later if we need one, but we don't need it for this.
The original thinking was that writing a restartpoint was more crucial
when in standby mode; but this way we've better performance and have a
low ceiling on the restart time if that should ever occur at the worst
Thanks again to Marko for the concept.
I'll work on the docs for backup.sgml also.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly