Re: Changing recovery.conf parameters into GUCs

On 29 March 2013 13:24, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Mar 29, 2013 at 9:59 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>> On 29 March 2013 01:17, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> > On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs <simon(at)2ndquadrant(dot)com>
>> > wrote:
>> Early discussions had difficulties because of the lack of config
>> directories, include_if_exists and this patch. We now have the
>> technical capability to meet every request. Circumstances have changed
>> and outcomes may change also.
>
> Thanks for the clarifications. The following questions are still unanswered:

Minor points only. We can implement this differently if you have
alternate proposals.

> 1) If recovery.trigger and recovery.conf are specified. To which one the
> priority is given?

Neither. No priority is required. If either is present we are triggered.

> 2) If both recovery.trigger and recovery.conf are used, let's imagine that
> the server removes recovery.trigger but fails in renaming recovery.conf but
> a reason or another. Isn't there a risk of inconsistency if both triggering
> methods are used at the same time?

No. If writes to the filesystem fail, you have much bigger problems.

> 3) Forcing a harcode of include_is_exists = 'recovery.conf' at the bottom of
> postgresql.conf doesn't look like a hack?

Well, that's just an emotive term to describe something you don't
like. There are no significant downsides, just a few lines of code,
like we have in many places for various purposes, such as the support
of multiple APIs for triggering standbys.

> 4) Based on your proposal, are all the parameters included in
> postgresql.conf.sample or not? Or only primary_conninfo, trigger_file and
> standby_mode?

Other values are specific to particular situations (e.g. PITR) and if
set in the wrong context could easily break replication. We could add
them if people wish it, but it would be commented out with a clear
"don't touch these" message, so it seems more sensible to avoid them
IMHO.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services