Re: Changing recovery.conf parameters into GUCs

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:
1) If recovery.trigger and recovery.conf are specified. To which one the
priority is given?
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?
3) Forcing a harcode of include_is_exists = 'recovery.conf' at the bottom
of postgresql.conf doesn't look like a hack?
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?
--
Michael