Re: [COMMITTERS] pgsql: Allow external recovery_config_directory

On 27 March 2013 14:20, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> On 27.03.2013 15:09, Simon Riggs wrote:
>>
>> On 27 March 2013 12:12, Heikki Linnakangas<hlinnakangas(at)vmware(dot)com>
>> wrote:
>>>
>>> On 27.03.2013 13:47, Simon Riggs wrote:
>>>>
>>>>
>>>> Allow external recovery_config_directory
>>>> If required, recovery.conf can now be located outside of the data
>>>> directory.
>>>> Server needs read/write permissions on this directory.
>>>
>>>
>>> This was a surprising commit. Does this get us any closer to merging
>>> postgresql.conf and recovery.conf?
>>
>>
>> Why so? I made a clear proposal on how to proceed and this was the
>> first part of it.
>
>
> You didn't answer the question. Does this get us any closer to merging
> postgresql.conf and recovery.conf? Why is this bundled in with that?

Why do you think these points are bundled? It clearly isn't and I've
not claimed it gets us any closer to that goal.

But it is the first part of two agreed changes. And I am now working
on the second, which is the recovery.conf GUCs.

> ISTM the quickest way forward is to revert this, and proceed with the rest
> of the plan: get Michael/Fujii's patch into shape, and commit it. If we
> still think this additional GUC is a good idea after that, we can add it
> afterwards just as well.

My review of that patch is on file and my rejection of it clear for
all to see. I have proposed a way forwards, which achieved agreement
then and I have made it clear all the way that I would work on that,
and am now doing so. None of that is a surprise. And Fujii will
receive credit for his contribution, which is the bit where we make
recovery parms into GUCs.

The quickest way forward is to proceed with The Plan as agreed on Dec
24 - Jan 9. Restarting a discussion and formulating an alternative
plan is just deliberate interference with no justification, especially
not when we pretend that the later plan somehow supercedes the earlier
agreed one, and certainly not just because a few months went by in
between.

In summary, we have clear agreement that a file needs to trigger
recovery. We have no reason to believe that renaming the trigger file
to something else is a good thing, hence recovery.conf should remain
and its contents be treated as GUCs. And recovery.conf now has the
option of living in a different directory, which needs to be writable.
So we have the new features desired, plus backwards compatibility. And
off I go to code now.

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