Re: Incremental backup from a streaming replication standby fails - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Incremental backup from a streaming replication standby fails
Date
Msg-id CA+TgmoZ2FrKX6WaDd8M-zqzR9Hr7bsVFOwo5ydCbeiSYz-2NdQ@mail.gmail.com
Whole thread Raw
In response to Re: Incremental backup from a streaming replication standby fails  (David Steele <david@pgmasters.net>)
Responses Re: Incremental backup from a streaming replication standby fails
List pgsql-hackers
On Fri, Jul 19, 2024 at 11:32 AM David Steele <david@pgmasters.net> wrote:
> I think it would be enough just to add a hint such as:
>
> HINT: this is possible when making a standby backup with little or no
> activity.

That could work (with "this" capitalized).

> My guess is in production environments this will be uncommon.

I think so too, but when it does happen, confusion may be common.

> Having said that, I think it would be better if it worked even if it
> does produce an empty backup. An empty backup wastes some disk space but
> if it produces less friction and saves an admin having to intervene then
> it is probably worth it. I don't immediately see how to do that in a
> reliable way, though, and in any case it seems like something to
> consider for PG18.

Yeah, I'm pretty reluctant to weaken the sanity checks here, at least
in the short term. Note that what the check is actually complaining
about is that the previous backup thinks that the WAL it needs to
replay to reach consistency ends after the start of the current
backup. Even in this scenario, I'm not positive that everything would
be OK if we let the backup proceed, and it's easy to think of
scenarios where it definitely isn't. Plus, it's not quite clear how to
distinguish the cases where it's OK from the cases where it isn't.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Built-in CTYPE provider
Next
From: Fujii Masao
Date:
Subject: Re: Add new COPY option REJECT_LIMIT