Re: unite recovery.conf and postgresql.conf

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Simon Riggs <simon@2ndQuadrant.com>

Cc: Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2011-09-25T16:58:07Z

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

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sat, Sep 24, 2011 at 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Okay, so you do agree that eventually we want to be rid of
>> recovery.conf? I think everyone else agrees on that. But if we are
>> going to remove recovery.conf eventually, what is the benefit of
>> postponing doing so?

> My joyous rush into agreeing to removal has since been replaced with
> the cold reality that we must support backwards compatibility.
> Emphasise "must".

[ shrug... ]  I do not agree with your conclusion.  We have to break
some eggs to make this omelet.  The reason why we have a mess here is
that the recovery.conf mechanism, which was designed with only the
one-shot archive-recovery case in mind, has been abused beyond its
capacity.  If we don't break with past practice we are not going to be
able to fix it.  And it's not like we don't break configuration file
contents in most releases anyway, so I really fail to see why this one
has suddenly become sacrosanct.

			regards, tom lane