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