On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat <r...@xzilla.net> wrote:
> On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus <j...@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.


pg_ctl standby
    will startup a server in standby mode, do not implicitly include
recovery.conf and disallow recovery_target parameters in
    (you may, if you wish, explicitly have "include recovery.conf" in
your postgresql.conf, should you desire that)


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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to