Re: recovery.conf location - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: recovery.conf location
Date
Msg-id 1285936852.1722.1917.camel@ebony
Whole thread Raw
In response to Re: recovery.conf location  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: recovery.conf location
List pgsql-hackers
On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus <josh@agliodbs.com> wrote:
> > On 9/29/10 7:54 PM, Tom Lane wrote:
> >> Robert Haas <robertmhaas@gmail.com> writes:
> >>> But that's not what Tom is talking about, I don't think: you might
> >>> also want a way to explicitly whack the flag in pg_control around.
> >>> That would probably be along the lines of pg_resetxlog.  I'm not sure
> >>> how much use case there is for such a thing, but if it's needed it's
> >>> certainly wouldn't be hard to write.
> >>
> >> Right, but instead of having to provide such a tool, we could just
> >> store the status as a text file.  There is a pretty time-honored
> >> tradition for that, ya know.
> >
> > And then move all the other config parameters to postgresql.conf?
> 
> The consensus seems to be to move only parameters for the standby server
> (except standby_mode) to postgresql.conf. That is, primary_conninfo and
> trigger_file.

I think we should allow them to be set in both places. I see no point at
all in invalidating everybody's configuration settings; we have many
external products that use this, various open source projects rely on it
plus everybody's roll-your-own scripts.

All new settings would be added to postgresql.conf

We can keep recovery.conf but recommend it is now left empty. So the
status is the existence of that file, just as it is now.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: WIP: extensible enums
Next
From: Tom Lane
Date:
Subject: Re: wip: functions median and percentile