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

Re: Feature Request: pg_replication_master()

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: 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-03 19:45:32
Message-ID: CA+U5nMKW3VDtmOVO-3R2a2tePmt=3-9zHx6Dq9oAuvi6A7RKBA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2013-01-03 20:02:12
Subject: Re: Review of Row Level Security
Previous:From: Magnus HaganderDate: 2013-01-03 19:33:35
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

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