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. 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers