Re: [proposal] recovery_target "latest"

From: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [proposal] recovery_target "latest"
Date: 2019-11-05 10:39:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Attached new version of a patch with TAP test.

On 11/5/19 11:51 AM, Grigory Smolkin wrote:
> Thank you for you interest in this topic!
> On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote:
>> Hello.
>> At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin
>> <g(dot)smolkin(at)postgrespro(dot)ru> wrote in
>>> Hello, hackers!
>>> I`d like to propose a new argument for recovery_target parameter,
>>> which will stand to recovering until all available WAL segments are
>>> applied.
>>> Current PostgreSQL recovery default behavior(when no recovery target
>>> is provided) does exactly that, but there are several shortcomings:
>>>    - without explicit recovery target standing for default behavior,
>>> recovery_target_action is not coming to action at the end of recovery
>>>    - with PG12 changes, the life of all backup tools became very hard,
>>> because now recovery parameters can be set outside of single config
>>> file(recovery.conf), so it is impossible to ensure, that default
>>> recovery behavior, desired in some cases, will not be silently
>>> overwritten by some recovery parameter forgotten by user.
>>> Proposed path is very simple and solves the aforementioned problems by
>>> introducing new argument "latest" for recovery_target parameter.
>> Does the tool remove or rename recovery.conf to cancel the settings?
>> And do you intend that the new option is used to override settings by
>> appending it at the end of postgresql.conf? If so, the commit
>> f2cbffc7a6 seems to break the assumption. PG12 rejects to start if it
>> finds two different kinds of recovery target settings.
> Yes, previously it was possible to remove/rename old recovery.conf,
> but not anymore.
> My assumption is exactly that PG should reject to start because of
> multiple recovery targets.
> Failing to start is infinitely better that recovering to the wrong
> recovery target.
>>> Old recovery behavior is still available if no recovery target is
>>> provided. I`m not sure, whether it should it be left as it is now, or
>>> not.
>>> Another open question is what to do with recovery_target_inclusive if
>>> recovery_target = "latest" is used.
>> Anyway inclusiveness doesn't affect to "immediate". If we had the
>> "latest" option, it would behave the same way.
> Right, thank you.
>> regards.
Grigory Smolkin
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
0002-recovery_target_latest.patch text/x-patch 7.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2019-11-05 11:18:12 Re: tableam vs. TOAST
Previous Message Kyotaro Horiguchi 2019-11-05 10:27:48 Re: Refactor parse analysis of EXECUTE command