On 9/9/11 7:05 AM, Tom Lane wrote:
> Magnus Hagander <mag...@hagander.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
