From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-10-31 19:05:02 |
Message-ID: | 4EAEF15E.1050407@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-10-31 19:11:16 | LDAP server docs |
Previous Message | Merlin Moncure | 2011-10-31 18:34:11 | Re: Multiple queries in transit |