> 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.
PostgreSQL Experts Inc.
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2011-10-31 19:11:16|
|Subject: LDAP server docs|
|Previous:||From: Merlin Moncure||Date: 2011-10-31 18:34:11|
|Subject: Re: Multiple queries in transit|