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

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.

recovery_target=immediate + r_t_action=shutdown for a standby works as
commanded. Do we need to inhibit that, too?

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

--
Kyotaro Horiguchi
NTT Open Source Software Center