Re: [proposal] recovery_target "latest"

From: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [proposal] recovery_target "latest"
Date: 2019-11-06 10:55:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 11/6/19 12:56 PM, Fujii Masao wrote:
> On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru> wrote:
>> On 11/6/19 10:39 AM, Peter Eisentraut wrote:
>>> This seems to also be related to this discussion:
>>> <>
>> 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
Thank you for pointing this out, I will work on it.

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:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2019-11-06 11:03:12 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message rtorre 2019-11-06 10:37:33 Re: [Proposal] Arbitrary queries in postgres_fdw