On Thu, Dec 1, 2016 at 8:28 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
