On Mon, 2006-08-07 at 13:05 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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.
OK, agreed.
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
moment.
Thanks again to Marko for the concept.
I'll work on the docs for backup.sgml also.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
