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 →
  1. Restructure error handling in reading of postgresql.conf.

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