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.
There is no significant additional code or complexity required to do
this, but it adds considerable usefulness.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services