Re: Feature Request: pg_replication_master()

On Wed, Dec 26, 2012 at 3:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> There already are two ways to promote a server out of recovery. One is
>> creating the trigger file. The other is "pg_ctl promote". (it uses a
>> trigger file called $PGDATA/promote internally, but that's invisible to
>> the user).
>
> Right, I was thinking of the trigger file to put a server *into*
> replication. That is, recovery.conf.

Well, we can't put the server back into recovery once it's up and
running. You have to restart for that, and I can't see that changing
any time soon. I think we could support something like:

pg_ctl start -m recover

Of course, that would require that primary_conninfo et. al. be
available from somewhere. If we got rid of all the recovery.conf
parameters and made them GUCs, then that'd be pretty easy: the setting
would always be available from postgresql.conf, but would be ignored
except when starting in recovery mode.

In my view, the biggest problem with recovery.conf is that the
parameters in there are not GUCs, which means that all of the
infrastructure that we've built for managing GUCs does not work with
them. As an example, when we converted recovery.conf to use the same
lexer that the GUC machinery uses, it allowed recovery.conf values to
be specified unquoted in the same circumstances where that was already
possible for postgresql.conf. But, you still can't use SHOW or
pg_settings with recovery.conf parameters, and I think pg_ctl reload
doesn't work either. If we make these parameters into GUCs, then
they'll work the same way everything else works. Even if (as seems
likely) we end up still needing a trigger file (or a special pg_ctl
mode) to initiate recovery, I think that's probably a win.

Other people's mileage may vary, of course.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company