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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company