On 9 January 2017 at 19:50, Peter Eisentraut
<peter.eisentraut@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
