Re: recovery.conf location
От | Thom Brown |
---|---|
Тема | Re: recovery.conf location |
Дата | |
Msg-id | AANLkTimRLWYRYiP27O0zGYr=wFK4DWdn8unW9=CYM64E@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: recovery.conf location (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 1 October 2010 15:41, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Oct 1, 2010 at 8:40 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> 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. > > +1. Getting recovery.conf to be parsed using the same code we use for > parsing postgresql.conf would be nice from a code cleanup point of > view, too. If you're going to do that, just make it clear which conf file's settings take precedence if someone accidental puts a setting in both.Presumably the recovery.conf file's settings wouldtake precedence. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
В списке pgsql-hackers по дате отправления: