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

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:
>>>> On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin
>>>> <g.smolkin@postgrespro.ru> wrote:
>>>>> On 11/6/19 10:39 AM, Peter Eisentraut wrote:
>>>>>> This seems to also be related to this discussion:
>>>>>> <https://www.postgresql.org/message-id/flat/993736dd3f1713ec1f63fc3b653839f5@lako.no>
>>>>> Yes, in a way. Strengthening current lax recovery behavior is a very
>>>>> good idea.
>>>>>
>>>>>> I like this idea.
>>>>>>
>>>>>> I don't like the name "latest".  What does that mean?  Other
>>>>>> documentation talks about the "end of the archive".  What does that
>>>>>> mean?  It means until restore_command errors.  Let's think of a name
>>>>>> that reflects that better.  Maybe "all_archive" or something like
>>>>>> that.
>>>>> As with "immediate", "latest" reflects the latest possible state this
>>>>> PostgreSQL instance can achieve when using PITR. I think it is simple
>>>>> and easy to understand for an end user, which sees PITR as a way to go
>>>>> from one state to another. In my experience, at least, which is, of
>>>>> course, subjective.
>>>>>
>>>>> But if we want an argument name to be technically accurate, then, I
>>>>> think, something like "end-of-available-WAL"/"all-WAL", "end-of-WAL"
>>>>> is
>>>>> a way to go.
>>>> 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.


> 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?


>
>>> The other way around, as I see it, is to define RECOVERY_TARGET_LATEST
>>> as something more complex, for example, the latest possible endptr in
>>> latest WAL segment. But it is tricky, because WAL archive may keeps
>>> growing as recovery is progressing or, in case of standby, master
>>> keeps sending more and more WAL.
> regards.
>
-- 
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company