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