Re: unite recovery.conf and postgresql.conf
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-09-20T17:09:29Z
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, Sep 20, 2011 at 1:01 PM, Josh Berkus <josh@agliodbs.com> wrote: > I'll go further and say that we only want one trigger file by default, > one which either enables or disables recovery. I'll further suggest > that we: > > a) have a standby.on file which puts the server in replica/recovery mode > if it's detected on startup, and > b) that we poll for the standby.on file going away as a trigger to stop > recovery and bring up the server in master mode, and > c) that pg_basebackup automatically create a standby.on file. It seems a bit confusing to me to have a file that takes effect only at startup when created but anytime when removed. I think one of the insufficiently-lauded 9.1 features is Fujii Masao's "pg_ctl promote". Now THAT is a good interface. Unlike trigger_file, it doesn't require any advance preparation, or monkeying with files on disk. You just tell it to promote, and it does. Sweet. Now it turns out that it uses a file to make that happen behind the scenes, but who cares? From the user's perspective It Just Works. I like the idea of some kind of sentinel file that tells the server to start up in recovery mode. But instead of having the user remove it to cause a promotion, I think the server should remove it when it does promote. That's more like what we've done in the past, and it ties in very nicely with what pg_ctl promote already does. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company