On Tue, Nov 1, 2011 at 9:11 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 11/1/11 12:29 PM, Robert Treat wrote: >> "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". > > Gah. > > There is no way we're getting distro packagers to switch from pg_ctl > start. Also, a lot of distros use the "postgres" command rather than > pg_ctl anything. > > Messing with pg_ctl is not really a solution for this, since few people > in production environments call it directly. Nobody I know, anyway. > > So Simon's suggested compromise still puts backwards compatibility ahead > of promoting the new API. This would result in nobody supporting the > new API until the day we remove the old one from the code.
Which will never happen, since part of the proposal is that PITR will only be supported using the old method. > I think adding "recovery_conf_location = ''" to postgresql.conf is a > much better compromise. Assuming we can stand the code complexity ... I think that might have some possibilities. But how does that work in detail? If you set it to empty, then the recovery_* parameters are just GUCs, I suppose: which seems fine. But if you set it to a non-empty value then what happens, exactly? The recovery.conf settings clobber anything in postgresql.conf, and when we exit recovery we reload the config, discarding any settings we got from recovery.conf? That might not be too bad. I think we need to back up and figure out what problem we're trying to solve here. IMV, the answer is "setting up a standby is too complicated and requiring yet another configuration file to do it makes it even more complicated". If the mechanism we introduce to "solve" that problem is more complicated than what we have now, it might end up being a net regression in terms of usability. I feel like changing everything that's currently in recovery.conf to GUCs and implementing SET PERSISTENT would give everyone what they need, admittedly without perfect backward compatibility, but perhaps close enough for government work, and a step forward overall. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers