Skip site navigation (1) Skip section navigation (2)

Re: unite recovery.conf and postgresql.conf

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

> 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.

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-10-31 19:11:16
Subject: LDAP server docs
Previous:From: Merlin MoncureDate: 2011-10-31 18:34:11
Subject: Re: Multiple queries in transit

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group