Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

On Tue, Nov 1, 2011 at 2:34 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat <rob@xzilla.net> wrote:
>> On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus <josh@agliodbs.com> wrote:
>>>
>>>> So, we have four potential paths regarding recovery.conf:
>>>>
>>>> 1) Break backwards compatibility entirely, and stop supporting recovery.conf as a trigger file at all.
>>>
>>> Note that is exactly what I have suggested when using "standby" mode
>>> from pg_ctl.
>>>
>>> But you already know that, since you said "If it's possible to run a
>>> replica without having a recovery.conf file,
>>> then I'm fine with your solution", and I already confirmed back to you
>>> that would be possible.
>>>
>>
>> "It's possible to run a replica without having a recovery.conf file"
>> is not the same thing as "If someone makes a recovery.conf file, it
>> won't break my operations". AIUI, you are not supporting the latter.
>
> Yes, that is part of the "combined proposal", which allows both old
> and new APIs.
>
> New API
>
> pg_ctl standby
>    will startup a server in standby mode, do not implicitly include
> recovery.conf and disallow recovery_target parameters in
> postgresql.conf
>    (you may, if you wish, explicitly have "include recovery.conf" in
> your postgresql.conf, should you desire that)
>
> Old API
>
> pg_ctl start
> and a recovery.conf has been created
>   will startup a server in PITR and/or replication, recovery.conf
> will be read automatically (as now)
>   so the presence of the recovery.conf acts as a trigger, only if we
> issue "start"
>
> So the existing syntax works exactly as now, but a new API has been
> created to simplify things in exactly the way requested. The old and
> the new API don't mix, so there is no confusion between them.
>
> You must still use the old API when you wish to perform a PITR, as
> explained by me, following comments by Peter.
>

Ah, thanks for clarifying, your earlier proposal didn't read that way
to me. It still doesn't solve the problem for tool makers of needing
to be able to deal with two possible implementation methods, but it
should be easier for them to make a choice. One thing though, I think
it would be better to have this work the other way around. ISTM we're
going to end up telling people to avoid using pg_ctl start and instead
use pg_ctl standby, which doesn't feel like the right answer. Ie.
"Starting in 9.2, you should use pg_ctl standby to launch your
database for normal operations and/or in cases where you are writing
init scripts to control your production databases. For backwards
compatibility, if you require the old behavior of using a
recovery.conf, we would recommend you use pg_ctl start instead".

Robert Treat
conjecture: xzilla.net
consulting: omniti.com