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.smolkin@postgrespro.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: http://www.postgrespro.com
The Russian Postgres Company
