Re: Feature Request: pg_replication_master()

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
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

> 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.

In response to


Browse pgsql-hackers by date

  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" isrun