Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id CAHGQGwGoJ-S_o4fNr3z=m2bq89jehhD6KWtSD2vgtnEP3ygPyQ@mail.gmail.com
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: unite recovery.conf and postgresql.conf
List pgsql-hackers
On Sat, Sep 10, 2011 at 12:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Sep 9, 2011 at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> I have to wonder though, if it wouldn't be less confusing to just get
>>> rid of recovery.conf and use a *different* file for this. Just to make
>>> it clear it's not a config file, but just a boolean exists/notexists
>>> state.
>>
>> +1.  If it's not a configuration file anymore, it shouldn't be called
>> one.
>
> +1 to rename file
>
> +1 to overall concept, just thinking same myself, not looked at patch yet

Are you still thinking the backward-compatibility (i.e., the
capability to specify
recovery parameters in recovery.conf) is required?

Even if we maintain the backward-compatibility, if we rename the file, ISTM
that the tools which depends on recovery.conf would need to be changed so
that <file-with-new-name> is used instead of recovery.conf. So I'm not sure
whether leaving the capability to set parameters in recovery.conf as it is is
really worth supporting or not. If we would like to make our effort for the
backward-compatibility more worthwhile, we might have to make the path of
the file configurable as a user can set it to "recovery.conf".

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: collation, arrays, and ranges
Next
From: Jun Ishiduka
Date:
Subject: Re: Online base backup from the hot-standby