Re: unite recovery.conf and postgresql.conf

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-10-11 14:29:51
Message-ID: 201110111429.p9BETp212229@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao wrote:
> On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >
> >>> Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
> >>> provide parameters solely for recovery. That is difficult to do
> >>> without causing all downstream tools to make major changes in the ways
> >>> they supply parameters.
> >>
> >> Actually, this case is easily solved by an "include recovery.conf"
> >> parameter. ?So it's a non-issue.
> >
> > That is what I've suggested and yes, doing that is straightforward.
>
> Even if we do that, you still need to modify the tool so that it can handle
> the recovery trigger file. recovery.conf is used as just a configuration file
> (not recovery trigger file at all). It's not renamed to recovery.done at the
> end of recovery. If the tool depends on the renaming from recovery.conf
> to recovery.done, it also would need to be modified. If the tool needs to
> be changed anyway, why do you hesitate in changing it so that it adds
> "include recovery.conf" into postgresql.conf automatically?
>
> Or you think that, to keep the backward compatibility completely,
> recovery.conf should be used as not only a configuration file but also a
> recovery trigger one and it should be renamed to recovery.done at
> the end of recovery?

As much as I appreciate Simon's work in this area, I think we are still
unclear if keeping backward-compatibility is worth the complexity
required for future users. Historically we have been bold in changing
postgresql.conf settings to improve clarity, and that approach has
served us well.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-10-11 15:05:18 Re: SET variable - Permission issues
Previous Message PostgreSQL - Hans-Jürgen Schönig 2011-10-11 14:07:06 Re: index-only scans