Re: Proposal for changes to recovery.conf API

On Thu, Dec 1, 2016 at 8:28 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs <simon@2ndquadrant.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.

Well, as to #1, we're making that an error IIUC.  But I see the point
of #2, for sure.  So sounds good to me.

>>> * 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?

Or instead.

>>> * 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.

If it were up to me, I'd keep the hot_standby parameter around but
default it to 'on'.

>>> * trigger_file renamed to promote_trigger_file
>>
>> Why?
>
> Because this is a trigger file aimed at doing promotion, not something else.

Oh, I see.  Makes sense.  I was confused.

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