Re: unite recovery.conf and postgresql.conf
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-10-11T14:29:51Z
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 →
-
Restructure error handling in reading of postgresql.conf.
- d56b3afc0376 9.2.0 cited
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. +