Horton

Re: unite recovery.conf and postgresql.conf

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-16T12:25:44Z
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 fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote:
> #1
> Use empty recovery.ready file to enter arhicve recovery. recovery.conf
> is not read automatically. All recovery parameters are expected to be
> specified in postgresql.conf. If you must specify them in recovery.conf,
> you need to add "include 'recovery.conf'" into postgresql.conf. But note
> that that recovery.conf will not be renamed to recovery.done at the
> end of recovery. This is what the patch I've posted does. This is
> simplest approach, but might confuse people who use the tools which
> depend on recovery.conf. 

A small variant to this:  When you are actually doing recovery from a
backup, having a recovery trigger and a recovery done file is obviously
quite helpful and necessary for safety.  But when you're setting up a
replication slave, it adds extra complexity for the user.  The
approximately goal ought to be to be able to do

pg_basebackup -h master -D there
postgres -D there --standby-mode=on --primary-conninfo=master

without the need to touch any obscure recovery trigger files.

So perhaps recovery.{trigger,ready} should not be needed if, say,
standby_mode=on.  But then what impact should the presence of
recovery.done have?