Re: unite recovery.conf and postgresql.conf
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Joshua Berkus <josh@agliodbs.com>
Cc: Robert Treat <rob@xzilla.net>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-01T17:34:20Z
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
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus <josh@agliodbs.com> wrote: > So, we have four potential paths regarding recovery.conf: > > 1) Break backwards compatibility entirely, and stop supporting recovery.conf as a trigger file at all. Note that is exactly what I have suggested when using "standby" mode from pg_ctl. But you already know that, since you said "If it's possible to run a replica without having a recovery.conf file, then I'm fine with your solution", and I already confirmed back to you that would be possible. > 2) Offer backwards compatibility only if "recovery_conf='filename'" is set in postgresql.conf, then behave like Simon's compromise. > > 3) Simon's compromise. See above. Calling it a compromise in this way implies nobody has been given exactly what they ask for, but that is not the case. > 4) Don't ever change how recovery.conf works. > > The only two of the above I see as being real options are (1) and (2). (3) would, as Robert points out, cause DBAs to have unpleasant surprises when some third-party tool creates a recovery.conf they weren't expecting. So: Please read my proposal again. I'll be happy to answer questions if you have any. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services