Re: Feature Request: pg_replication_master()

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-09 20:42:25
Message-ID: 20130109204225.GB21747@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 3, 2013 at 07:45:32PM +0000, Simon Riggs wrote:
> On 3 January 2013 18:35, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> > 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.
>
> That may be possible in 9.3 since we have a patch from Fujii-san. I'll
> hack that down to just the GUC part once we start the next CF.
>
> My personal priority is the shutdown checkpoint patch over that though.
>
> > 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.
>
> No pushing required. When we have a reasonable proposal that improves
> on the current state, we can implement that.

Sounds like we are all in agreement and on a good track to completion.
I apologize for overreacting and thinking we were not addressing this
issue objectively. Thanks for the discussion.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-09 20:43:19 Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Simon Riggs 2013-01-09 20:36:05 Reducing size of WAL record headers