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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
