From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Feature Request: pg_replication_master() |
Date: | 2013-01-03 18:35:22 |
Message-ID: | 50E5CF6A.2060403@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert,
> 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.
I agree that it would be an improvement, and I would be happy just to
see the parameters become GUCs.
I'm just saying that I'll still be pushing to get rid of the requirement
for recovery.conf in 9.4, that's all.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-01-03 18:36:15 | Re: pg_upgrade test script creates port conflicts in parallel testing |
Previous Message | Heikki Linnakangas | 2013-01-03 18:01:41 | pgsql: Tolerate timeline switches while "pg_basebackup -X fetch" is run |