Re: [proposal] recovery_target "latest" - Mailing list pgsql-hackers

On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote:
> At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin <g.smolkin@postgrespro.ru> wrote in
>> On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
>>> At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
>>> <g.smolkin@postgrespro.ru> wrote in
>>>> On 11/6/19 1:55 PM, Grigory Smolkin wrote:
>>>>> On 11/6/19 12:56 PM, Fujii Masao wrote:
>>>>>> What happens if this parameter is set to latest in the standby mode?
>>>>>> Or the combination of those settings should be prohibited?
>>>>> Currently it will behave just like regular standby, so I think, to
>>>>> avoid confusion and keep things simple, the combination of them should
>>>>> be prohibited.
>>>>> Thank you for pointing this out, I will work on it.
>>>> Attached new patch revision, now it is impossible to use
>>>> recovery_target 'latest' in standby mode.
>>>> TAP test is updated to reflect this behavior.
>>> In the first place, latest (or anything it could be named as) is
>>> defined as the explit label for the default behavior. Thus the latest
>>> should work as if nothing is set to recovery_target* following the
>>> definition.  That might seems somewhat strange but I think at least it
>>> is harmless.
>>
>> Well, it was more about getting default behavior by using some
>> explicit recovery_target, not the other way around. Because it will
>> break some 3rd party backup and replication applications, that may
>> rely on old behavior of ignoring recovery_target_action when no
>> recovery_target is provided.
>> But you think that it is worth pursuing, I can do that.
> Ah. Sorry for the misleading statement. What I had in my mind was
> somewhat the mixture of them.  I thought that recovery_target =''
> behaves the same way as now, r_t_action is ignored. And 'latest' just
> makes recovery_target_action work as the current non-empty
> recovery_target's does. But I'm not confident that it is a good
> design.
>
>>> recovery_target=immediate + r_t_action=shutdown for a standby works as
>>> commanded. Do we need to inhibit that, too?
>> Why something, that work as expected, should be inhibited?
> To make sure, I don't think we should do that. I meant by the above
> that standby mode is already accepting recovery_target_action so
> inhibiting that only for 'latest' is not orthogonal and could be more
> confusing for users, and complicatig the code. So my opinion is we
> shouldn't inhibit 'latest' unless r_t_action harms.

I gave it some thought and now think that prohibiting recovery_target 
'latest' and standby was a bad idea.
All recovery_targets follow the same pattern of usage, so 
recovery_target "latest" also must be capable of working in standby mode.
All recovery_targets have a clear deterministic 'target' where recovery 
should end.
In case of recovery_target "latest" this target is the end of available 
WAL, therefore the end of available WAL must be more clearly defined.
I will work on it.

Thank you for a feedback.


>
> regards.
>
-- 
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company