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.

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


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to