Re: Proposal for changes to recovery.conf API

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, 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>, 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: 2017-01-01 21:14:57
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 20 December 2016 at 15:11, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 20 December 2016 at 15:03, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> API for crash recovery will never be changed. That is, crash recovery needs
>> neither recovery.trigger nor standby.trigger. When the server starts a crash
>> recovery without any trigger file, any recovery parameter settings in
>> postgresql.conf are ignored. Right?
> Yes. There are no conceptual changes, just the API.
> The goals are: visibility and reloading of recovery parameters,
> removal of special case code.

OK, so here's the patch, plus doc cleanup patch.

Trying to fit recovery targets into one parameter was really not
feasible, though I tried. Michael's suggested approach of using
recovery_target_type and recovery_target_value has been more
practical, bearing in mind the 3 other relevant parameters.

1. 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

2. Signal files can be placed in a writable directory outside of the
data directory, signal_file_directory

3. To signal recovery, create an empty recovery.signal file. Same as
recovery.conf with standby_mode = off

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

5. recovery.conf parameters are all moved to postgresql.conf, with these changes
a) standby_mode no longer exists
b) trigger_file no longer exists… create a file in signal_directory
are two new parameters that specify the most important type and value of
targeted recovery, though there are other parameters that affect the
outcome also.

recovery_target_type = ‘xid’
recovery_target_value = ‘1234’

d) recovery target are now reloadable, not server start only

e) recovery parameters are shown in the postgresql.conf.sample, but
commented out

f) primary_conninfo and primary_slotinfo are renamed to
sender_conninfo and sender_slotinfo to more accurately reflect that these
parameters are no longer primary/master only

g) Recovery Config chapter in docs is retained (for now, at least) and
will later add a link from the main docs to explain this.

I've left the following points for later discussion/cleanup

* recovery.conf.sample will be removed

* 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

Tests have been modified also, but regrettably at this point only 5
out of 8 regression tests pass. This is most likely because I've had
to make more complex changes around timeline handling. I'll post again
tomorrow when I fix them.

Next steps I plan for this release

* Relocate some more code out of xlog.c and guc.c

* Full rewrite of main text docs

* pg_ctl demote
Allows us to avoid incrementing the timeline when performing a switchover

Simon Riggs
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
newRecoveryAPI_doc1.v101.patch application/octet-stream 17.0 KB
newRecoveryAPI.v101y.patch application/octet-stream 71.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-01-01 23:04:38 Re: [HACKERS] French translation encoding
Previous Message Tom Lane 2017-01-01 20:22:13 Re: Fixing pgbench's logging of transaction timestamps