Fujii Masao wrote:
> On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus <josh@agliodbs.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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +