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
