Horton

Re: unite recovery.conf and postgresql.conf

Fujii Masao <masao.fujii@gmail.com>

View thread
From: Fujii Masao <masao.fujii@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-13T05:46:17Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restructure error handling in reading of postgresql.conf.

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