On Fri, Dec 2, 2016 at 10:10 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Dec 1, 2016 at 7:31 PM, Simon Riggs <si...@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
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
>> * 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
Because this is a trigger file aimed at doing promotion, not something else.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: