Re: unite recovery.conf and postgresql.conf

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