Re: Proposal for changes to recovery.conf API

On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> * pg_basebackup -R
>> will write recovery.trigger to data directory
>> insert parameters postgresql.conf.auto, if possible
>
> Don't understand that last line; otherwise, +1.

pg_basebackup -R creates a recovery.conf now, by appending the
parameters to postgresql.conf.auto we are sure that:
1) there is no need to check for the existence of recovery.conf as it
could be included by postgresql.conf with something like an
include_if_exists
2) postgresql.conf.auto is loaded automatically without any additional
tweaks needed in the GUC parsing code paths.

>> * Add docs: "Guide to changes in recovery.conf in 10.0"
>
> Hmm, we don't usually write the docs in terms of how things are
> different from a previous version. Might seem strange in 5 years.
> Not sure what's best, here.

A good chunk in the release notes would make sense as well?

>> * recovery_target as a single parameter, using proposed "xid 666"
>> "target value" format
>
> +1.
>
>> * remove hot_standby parameter altogether, in line with earlier changes
>
> That seems a little surprising. We don't think anyone ever wants to
> refuse connections during archive recovery?

I suggested that yesterday. We have talked as well about merging
standby_mode with hot_standby, but at the end most use cases I have
seen involve looking at pg_is_in_recovery() these days to determine if
a node is out of recovery of not, and this makes particularly more
sense since 9.6 where wal_level = archive <=> hot_standby. The thought
behind that is also partially that people complain that replication is
too hard to understand for people.

>> * trigger_file renamed to promote_trigger_file
>
> Why?

Because this is a trigger file aimed at doing promotion, not something else.
--
Michael