On Fri, Sep 16, 2011 at 3:54 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This seems like it's already predetermining the outcome of the argument
>> about recovery.conf. Mind you, I'm not unhappy with this choice, but
>> it's hardly implementing only behavior that's not being debated.
>>
>> If we're satisfied with not treating recovery-only parameters different
>> from run-of-the-mill GUCs, this is fine.
>
> Okay, we need to reach a consensus about the treatment of
> recovery.conf.
>
> We have three choices.
What we should focus on is these requirements
1. Don't break software that relies on the existing behaviour
2. Allow parameters to be reloaded at SIGHUP
3. Allow recovery parameters to be handled same way as other GUCs
4. We need to retain recovery.conf/.done style behaviour to mark end
of archive recovery
Making an automatic include makes (2) and (3) work OK, without
breaking (1). I haven't seen another solution that doesnt break (1).
Rename of .conf to .done allows us to maintain working code for
existing solutions (there are *many* out there...)
We should say that the automatic include only works during recovery,
so if someone puts recovery.conf back then we ignore it.
If we treat recovery,conf as being read *first* then any parameter
mentioned twice (i.e. mentioned again in postgresql.conf) will
override the setting in recovery.conf and we have no issues.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services