Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread 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


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-03 18:36:15
Subject: Re: pg_upgrade test script creates port conflicts in parallel testing
Previous:From: Heikki LinnakangasDate: 2013-01-03 18:01:41
Subject: pgsql: Tolerate timeline switches while "pg_basebackup -X fetch" isrun

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group