Re: Proposal for changes to recovery.conf API

On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> This is a summary of proposed changes to the recovery.conf API for
> v10. These are based in part on earlier discussions, and represent a
> minimal modification to current usage.

This looks great.

> Proposed changes (with reference to patches from Abhijit Menon-Sen and myself)
>
> * pg_ctl start -M (normal|recover|continue)
> pg_ctl can now start the server directly as a standby, similar to the
> way pg_ctl promote works. The internal implementation is also similar,
> with pg_ctl writing a "recovery.trigger" file that initiates recovery
> in the same way recovery.conf used to do. It is still possible to
> manually add a file called "recovery.trigger" and have that work if
> users desire that mechanism.
> Different startup methods can be selected with the <option>-M</option>
> option. <quote>Normal</quote> mode starts the server for read/write,
> overriding any previous use in Recover mode.
> <quote>Recover</quote> mode starts the server as a standby server which
> expects to receive changes from a primary/master server using physical
> streaming replication or is used for
> performing a recovery from backup. <quote>Continue</quote> mode is
> the default and will startup the server in whatever mode it was in at
> last proper shutdown, or as modified by any trigger files present.
> (Patch: recovery_startup_r10_api.v1b.patch)

I like this.  I think your choice of naming is good, too.  Michael
suggested something else downthread, but I think it's good to call
this "recover" because we don't know whether the user is doing
replication or PITR or whatever; "recover" is the internal name and is
fairly well-understood database jargon.

> * $DATADIR/recovery.conf no longer triggers recovery
> (Patch: recovery_startup_r10_api.v1b.patch)
>
> * Recovery parameters would now be part of the main postgresql.conf
> infrastructure
> Any parameters set in $DATADIR/recovery.conf will be read after the
> main parameter file, similar to the way that postgresql.conf.auto is
> read.
> (Abhijit)

Makes sense.

> * pg_basebackup -R will continue to generate a parameter file called
> recovery.conf as it does now, but will also create a file named
> recovery.trigger.
> (This part is WIP; patch doesn't include implementation for tar format yet)

Hmm, OK.

> * Parameters
> All of the parameters formerly set in recovery.conf can be set in
> postgresql.conf using RELOAD
> These parameters will have no defaults in postgresql.conf.sample
> Setting them has no effect during normal running, or once recovery ends.
>  https://www.postgresql.org/docs/devel/static/archive-recovery-settings.html
>  https://www.postgresql.org/docs/devel/static/recovery-target-settings.html
>  https://www.postgresql.org/docs/devel/static/standby-settings.html
> (Abhijit)

This sounds really good.

> Related cleanup
> * Promotion signal file is now called "promote.trigger" rather than
> just "promote"
> * Remove user configurable "trigger_file" mechanism - use
> "promote.trigger" for all cases

I'm in favor of this.  I don't think that it's very hard for authors
of backup tools to adapt to this new world, and I don't see that
allowing configurability here does anything other than create more
cases to worry about.

As you can see, I don't have a lot of substance to add, but I wanted
to lend my +1 to all of these proposals, which I think will improve
ease of use and probably lead to easier code maintenance, too.
Thanks!

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company