On 9 January 2017 at 19:50, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 1/1/17 4:14 PM, Simon Riggs wrote: >> OK, so here's the patch, plus doc cleanup patch. > > I don't think this patch is likely to succeed if we throw in more ideas > in every round. > > I think we have or are approaching agreement on moving recovery.conf > into postgresql.conf, making the settings reloadable, and adding signal > (formerly trigger) files to trigger recovery or standby. I think that > is a useful change, but it's already big enough and needs extensive > reviewing and testing. > > All the other stuff, such as regrouping the recovery parameters, > removing the hot_standby setting, renaming the primary_* parameters, > making the directory of the signal files configurable, should be > separate patches that should be discussed separately. I think the > arguments for these latter changes are weaker, and tactically I would > focus on getting the recovery.conf move in before thinking about all the > other ones.
Thanks for the review. * Removing hot_standby setting is not included in this patch; happy to keep that separate; very low priority * Renaming primary_* parameters - Currently we use this config setting even when connecting to a standby, so the parameter is confusingly named, so 10.0 is a good chance to name it correctly. Will submit as separate patch. * Directory for signal files was in my understanding a primary goal of the patch. I am happy to remove that into a later submission. That resolves, for now, the issue with pg_basebackup -R. The above changes are fairly minor. The main area of "design doubt" remains the implementation of the recovery_target parameter set. Are we happy with the user interface choices in the patch, given the understanding that the situation was more comple than at first thought? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
