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