Re: Incremental backup from a streaming replication standby fails

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Incremental backup from a streaming replication standby fails
Date: 2024-07-19 16:59:56
Message-ID: CA+TgmoZ2FrKX6WaDd8M-zqzR9Hr7bsVFOwo5ydCbeiSYz-2NdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 19, 2024 at 11:32 AM David Steele <david(at)pgmasters(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2024-07-19 17:08:39 Re: Add new COPY option REJECT_LIMIT
Previous Message Jeff Davis 2024-07-19 16:26:20 Re: Built-in CTYPE provider