Re: Request for vote to move forward with recovery.conf overhaul

On Sat, Jan 26, 2013 at 9:49 PM, Michael Paquier

<michael.paquier@gmail.com> wrote:
> On Sun, Jan 27, 2013 at 7:14 AM, Phil Sorber <phil@omniti.com> wrote:
>>
>> On Wed, Jan 23, 2013 at 6:36 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> >
>> > On 2013/01/23, at 18:12, Simon Riggs <simon@2ndQuadrant.com> wrote:
>> >
>> >> On 23 January 2013 04:49, Michael Paquier <michael.paquier@gmail.com>
>> >> wrote:
>> >>
>> >>> - recovery.conf is removed (no backward compatibility in this version
>> >>> of the
>> >>> patch)
>> >>
>> >> If you want to pursue that, you know where it leads. No, rebasing a
>> >> rejected patch doesn't help, its just relighting a fire that shouldn't
>> >> ever have been lit.
>> >>
>> >> Pushing to do that out of order is just going to drain essential time
>> >> out of this CF from all of us.
>> > No problem to support both. The only problem I see is if the same
>> > parameter is defined in recovery.conf and postgresql.conf, is the priority
>> > given to recovery.conf?
>>
>> I would think that if someone created a recovery.conf file they would
>> expect that to be given priority. Otherwise they would know that was a
>> deprecated method and would set it in postgresql.conf only.
>
> Please find attached an half-cooked patch supporting both postgresql.conf
> and recovery.conf. Priority is given to recovery.conf if the same parameter
> is specified in both files. I have updated the docs in consequence but I
> think they can be improved.
> The main modification here is in xlog.c:readRecoveryCommandFile where the
> deparsed output values of recovery.conf is transferred to the new GUCs using
> SetConfigOption($OPTION, $VALUE, PGC_POSTMASTER, PGC_S_OVERRIDE) as bridge.
> This does not work yet, SetConfigOption is not able to detect the new
> values. Comments?

So... what happens when recovery ends?  Do the settings loaded from
recovery.conf get reverted, or what?