On Wed, Dec 26, 2012 at 3:32 PM, Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers