Re: Proposal for changes to recovery.conf API

On 9 January 2017 at 19:50, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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