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-09-09 17:40:49
Message-ID: 4E6A4FA1.9050609@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 9/9/11 7:05 AM, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> I have to wonder though, if it wouldn't be less confusing to just get
>> rid of recovery.conf and use a *different* file for this. Just to make
>> it clear it's not a config file, but just a boolean exists/notexists
>> state.
> 
> +1.  If it's not a configuration file anymore, it shouldn't be called
> one.

I'm in favor of this.  People are sufficiently confused by the existing
behavior that we're not going to confuse them further by changing it.

In fact: currently we have a "trigger file" concept in recovery.conf.
Might we unite the trigger file concept with the concept of having a
file to indicate that server is a replica on startup?

i.e. in postgresql.conf we have two settings:

replication_status = {master,standby}
failover_trigger_file = ''  #defaults to $PGDATA/master_trigger

If replication_status = master, then the server is a standalone or
master node.

If replication_status = standby, then the server is a PITR, warm
standby, or hot standby replica.

If the failover_trigger_file is created and detected, then PostgreSQL
will reload in master mode.  replication_status will get set to "master"
so that it's easy to tell this from the command line.

The above would be a lot easier to comprehend than the current behavior,
and would allow us all of the same options the current behavoir does.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

pgsql-hackers by date

Next:From: Noah MischDate: 2011-09-09 17:44:05
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Previous:From: Tom LaneDate: 2011-09-09 17:30:57
Subject: Re: Moving core timestamp typedefs/macros somewhere else

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