Simon, > Everybody agrees a neater way of invoking standby mode would be good.
I don't think this goes far enough. The whole recovery.conf/recovery.done thing is a serious problem for automated management of servers and automated failover. So it's not just "a neater way would be good" but "using recovery.conf as a trigger file is a broken idea and needs to be changed." > These things are announced as deprecated and will be removed when we > go to release 10.0 > * trigger_file > * standby_mode > * recovery.conf indicates standby So you're idea is that people who don't want recovery.conf to be used as a trigger file would not have the file at all, but would have something like "replication.conf" instead? If it's possible to run a replica without having a recovery.conf file, then I'm fine with your solution. If it's not, then I find your solution not to be a solution at all. > recovery.conf should continue to be required to perform a PITR. If we > place the recovery_target parameters into postgresql.conf we will have > no way to differentiate between (1) a recovery that has successfully > completed then crashed and (2) a user-specified recovery, which was > the original rationale for its use. This is OK, since we now encourage > people to enter a recovery by creating recovery.conf and for entering > a standby to use a new cleaner API without the confusing use of the > word "recovery". Sure. recovery.conf worked fine for PITR. We've just overextended it for other purposes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
