Re: [HACKERS] Proposal for changes to recovery.conf API

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] Proposal for changes to recovery.conf API
Дата
Msg-id CANP8+jLawZ7XKOnenVFfgepY5_O9Lbu=MObdxmqP7OSyUmkzgQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal for changes to recovery.conf API  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [HACKERS] Proposal for changes to recovery.conf API  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Proposal for changes to recovery.conf API  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: [HACKERS] Proposal for changes to recovery.conf API  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On 20 December 2016 at 15:11, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 20 December 2016 at 15:03, Fujii Masao <masao.fujii@gmail.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
c)
recovery_target_type
recovery_target_value
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.

e.g.
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                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Fixing pgbench's logging of transaction timestamps
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables