Re: [PATCHES] Restartable Recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Restartable Recovery
Date
Msg-id 671.1154970338@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Restartable Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [PATCHES] Restartable Recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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.  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.

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.

            regards, tom lane

pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: AOL Research open-research
Next
From: Mark Wong
Date:
Subject: Re: AOL Research open-research