Re: Proposal for changes to recovery.conf API

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for changes to recovery.conf API
Date: 2016-12-19 22:11:03
Message-ID: CANP8+jLoYSDjB5ip7wynVcckoE4OynHabUnB8pQMgBJgFKQpiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19 December 2016 at 21:29, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 12/16/16 8:52 PM, Robert Haas wrote:
>> If the explanation is just a few sentences long, I see no reason not
>> to include it in the release notes.
>
> As far as I can tell from the latest posted patch, the upgrade
> instructions are
>
> - To trigger recovery, create an empty file recovery.trigger instead of
> recovery.conf.
>
> - All parameters formerly in recovery.conf are now regular
> postgresql.conf parameters. For backward compatibility, recovery.conf
> is read after postgresql.conf, but the parameters can now be put into
> postgresql.conf if desired.
>
> Some of that might be subject to patch review, but it's probably not
> going to be much longer than that. So I think that will fit well into
> the usual release notes section.

Although that's right, there is more detail.

The current list is this... based upon discussion in Tokyo dev meeting

* Any use of the earlier recovery.conf or any of the old recovery
parameter names causes an ERROR, so we have a clear API break

* To trigger recovery, create an empty recovery.trigger file. Same as
recovery.conf with standby_mode = off

* To trigger standby, create an empty standby.trigger file. Same as
recovery.conf with standby_mode = on

* Trigger files can be placed in a writable directory outside of the
data directory, trigger_directory
(I would also like to rename the concept of "trigger file" to another
word/phrase not already used for something else, c.f. table triggers)

* recovery.conf parameters are all moved to postgresql.conf, with these changes
a) standby_mode no longer exists
b) trigger_file is replaced by promote_trigger_file
equivalent parameters will be added for c) recovery_trigger_file and
d) standby_trigger_file
e) recovery_target is a new parameter with the two part content
mentioned upthread, e.g. 'xid 1234'
f) recovery_target and all trigger_file parameters are now reloadable,
not server start
g) recovery parameters are shown in the postgresql.conf.sample, but
commented out
h) recovery.conf.sample is removed
which leaves many of the parameters with same name and meaning as
before, but enough change to be a clear API break that needs people to
understand the changes

* pg_basebackup -R will generate a parameter file written to data
directory that will allow it to work, even when postgresql.conf is in
a different directory
(this bit was the most awkward part of the list of changes)

* hot_standby parameter would be removed

I think I can work this into the docs without anything worth further
discussion, but let me write that first.

The release notes can warn about the old API generating an ERROR, with
a multiple links to discussion of how it now works.

Merry Christmas everybody, new patch in time for New Year, further
discussion welcome

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-12-19 22:12:11 Re: Creating a DSA area to provide work space for parallel execution
Previous Message Peter Eisentraut 2016-12-19 21:37:33 Re: Proposal: add error message in backend/catalog/index.c