Re: Feature Request: pg_replication_master()

Simon,

> What the patch doesn't change is the requirement to have a file that
> causes the server to place itself into archive recovery. So there is
> no more recovery.conf and instead we have a file called
> recovery.trigger instead.

Requiring a file in order to make a server a replica is what we should
be trying to get away from. It should be possible to configure a server
as a replica by setting a GUC in PostgreSQL.conf (before first startup,
obviously). Naturally, this then links in with SET PERSISTENT or
however we're calling it these days in order to take a server out of
replica mode.

> We now support the concept of multiple .conf files, so continuing to
> use a file called recovery.conf for those parameters works just fine
> now without much effort. Note also that the recovery.conf requirement
> to put things in quotes still works when they are GUCs, its just no
> longer a requirement like it used to be. So previous files will work
> just fine.

You're assuming the current recovery.conf-->recovery.done arrangement,
or its analog, is a given. I'm saying that's the biggest thing we want
to change.

> Given the continuing need for a file to trigger recovery, changing the
> name of the file from recovery.conf to recovery.trigger just breaks
> backwards compatibility for absolutely no gain whatsoever (as long as
> we do (1)).

I agree. If we can't dump the trigger file, there's no good reason to
change its name. However, I want to get rid of the trigger file.

> From all of the above, I think its worth doing this
> * allowing recovery.conf to be in a different directory
> * make recovery config parameters into GUCs
> * no other changes to way things currently work

I agree that the above would be worth doing if that's all we can get
accomplished in 9.3. Let's determine that it is all we can get
accomplished before we settle, though.

From my perspective, the best API would be:

1. all current recovery.conf parameters get moved into PostgreSQL.conf.

2. we add a parameter called replication_role (or similar), which can be
"master","replica", or "warm_standby" (someone else can make a case for
"none" if there is one).

3. replica promotion is accomplished by one of 2 mechanisms:

a. user edits postgresql.conf, changes replication_role, and reloads.

b. pg_ctl promote, which also rewrites replication_role in
postgresql.conf (hence, link to SET PERSISTENT).

4. many current recovery.conf paramters become changeable with a HUP,
including primary_conninfo.

5. primary_conninfo supports the URI format as well as the present one.

While the replication change mechanisms of recovery.done and the
replication-ending trigger file are nice for some users, they aren't
(IMHO) valuable enough to be worth preserving if they would compromise
the above, much cleaner, API.

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