Subject: Incremental backup from a streaming replication standby

From: Laurenz Albe <[email-masked]>
Date: Sat, 29 Jun 2024 07:01:04 +0200

I played around with incremental backup yesterday and tried $subject

The WAL summarizer is running on the standby server, but when I try  
to take an incremental backup, I get an error that I understand to mean  
that WAL summarizing hasn't caught up yet.

I am not sure if that is working as designed, but if it is, I think it  
should be documented.

Yours,
Laurenz Albe

---

From: Laurenz Albe <[email-masked]>
Date: Mon, 15 Jul 2024 17:26:58 +0200

> I am not sure if that is working as designed, but if it is, I think it  

I played with this some more.  Here is the exact error message:

ERROR:  manifest requires WAL from final timeline 1 ending at 0/1967C260, but this backup starts at 0/1967C190

By trial and error I found that when I run a CHECKPOINT on the primary,
taking an incremental backup on the standby works.

I couldn't fathom the cause of that, but I think that that should either
be addressed or documented before v17 comes out.

Yours,
Laurenz Albe

---

From: Robert Haas <[email-masked]>
Date: Fri, 19 Jul 2024 10:52:45 -0400

> be addressed or documented before v17 comes out.

I had a feeling this was going to be confusing. I'm not sure what to
do about it, but I'm open to suggestions.

Suppose you take a full backup F; replay of that backup will begin
with a checkpoint CF. Then you try to take an incremental backup I;
replay will begin from a checkpoint CI. For the incremental backup to
be valid, it must include all blocks modified after CF and before CI.
But when the backup is taken on a standby, no new checkpoint is
possible. Hence, CI will be the most recent restartpoint on the
standby that has occurred before the backup starts. So, if F is taken
on the primary and then I is immediately taken on the standby without
the standby having done a new restartpoint, or if both F and I are
taken on the standby and no restartpoint intervenes, then CF=CI. In
that scenario, an incremental backup is pretty much pointless: every
single incremental file would contain 0 blocks. You might as well just
use the backup you already have, unless one of the non-relation files
has changed. So, except in that unusual corner case, the fact that the
backup fails isn't really costing you anything. In fact, there's a
decent chance that it's saving you from taking a completely useless
backup.

On the primary, this doesn't occur, because there, each new backup
triggers a new checkpoint, so you always have CI>CF.

The error message is definitely confusing. The reason I'm not sure how
to do better is that there is a large class of errors that a user
could make that would trigger an error of this general type. I'm
guessing that attempting a standby backup with CF=CI will turn out to
be the most common one, but I don't think it'll be the only one that
ever comes up. The code in PrepareForIncrementalBackup() focuses on
what has gone wrong on a technical level rather than on what you
probably did to create that situation. Indeed, the server doesn't
really know what you did to create that situation. You could trigger
the same error by taking a full backup on the primary and then try to
take an incremental based on that full backup on a time-delayed
standby (or a lagging standby) whose replay position was behind the
primary, i.e. CI<CF.

More perversely, you could trigger the error by spinning up a standby,
promoting it, taking a full backup, destroying the standby, removing
the timeline history file from the archive, spinning up a new standby,
promoting onto the same timeline ID as the previous one, and then
trying to take an incremental backup relative to the full backup. This
might actually succeed, if you take the incremental backup at a later
LSN than the previous full backup, but, as you may guess, terrible
things will happen to you if you try to use such a backup. (I hope you
will agree that this would be a self-inflicted injury; I can't see any
way of detecting such cases.) If the incremental backup LSN is earlier
than the previous full backup LSN, this error will trigger.

So, given all the above, what can we do here?

One option might be to add an errhint() to the message. I had trouble
thinking of something that was compact enough to be reasonable to
include and yet reasonably accurate and useful, but maybe we can
brainstorm and figure something out. Another option might be to add
more to the documentation, but it's all so complicated that I'm not
sure what to write. It feels hard to make something that is brief
enough to be worth including, accurate enough to help more than it
hurts, and understandable enough that people who run into this will be
able to make use of it.

I think I'm a little too close to this to really know what the best
thing to do is, so I'm happy to hear suggestions from you and others.

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

---

From: David Steele <[email-masked]>
Date: Fri, 19 Jul 2024 22:32:06 +0700

> decent chance that it's saving you from taking a completely useless

<snip>

> thing to do is, so I'm happy to hear suggestions from you and others.

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.

My guess is in production environments this will be uncommon.

For example, over the years we (pgBackRest) have gotten numerous bug 
reports that time-targeted PITR does not work. In every case we found 
that the user was just testing procedures and the database had no 
activity between backups -- therefore recovery had no commit timestamps 
to use to end recovery. Test environments sometimes produce weird results.

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.

Regards,
-David

---

From: Robert Haas <[email-masked]>
Date: Fri, 19 Jul 2024 12:59:56 -0400

> HINT: this is possible when making a standby backup with little or no

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.

> reliable way, though, and in any case it seems like something to

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.

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 19 Jul 2024 20:41:50 +0200

On Fri, 2024-07-19 at 12:59 -0400, Robert Haas wrote:
Thanks for looking at this.

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

I guess this will most likely happen during tests like the one I made.

I'd be alright with the hint, but I'd say "during making an *incremental*
standby backup", because that's the only case where it can happen.

I think it would also be sufficient if we document that possibility.
When I got the error, I looked at the documentation of incremental
backup for any limitations with standby servers, but didn't find any.
A remark in the documentation would have satisfied me.

Yours,
Laurenz

---

From: Robert Haas <[email-masked]>
Date: Fri, 19 Jul 2024 16:03:34 -0400

> A remark in the documentation would have satisfied me.

Would you like to propose a patch adding a hint and/or adjusting the
documentation? Or are you wanting me to do that?

---

From: Laurenz Albe <[email-masked]>
Date: Sat, 20 Jul 2024 00:07:36 +0200

> documentation? Or are you wanting me to do that?

Here is a patch.
I went for both the errhint and some documentation.

Yours,
Laurenz Albe
From a46b23afc919bfa0d0aa9bdad962b95a3ae407ec Mon Sep 17 00:00:00 2001
From: Laurenz Albe <[email-masked]>
Date: Sat, 20 Jul 2024 00:05:26 +0200
Subject: [PATCH v1] Add documentation and hint for incremental backup on
 standbys

Taking an incremental backup on a streaming replication standby immediately
after a base backup can result in the error

  manifest requires WAL from final timeline n ending at XXX, but this backup starts at YYY

This message looks scary, even though the only problem is that the backup
would be empty and thus it makes no sense to take it anyway.

Add a clarifying errhint and some documentation to mitigate the problem.

Author: Laurenz Albe
Reviewed-by: Robert Haas, David Steele
Discussion: https://postgr.es/m/[email-masked]

Backpatch to v17.
---
 doc/src/sgml/backup.sgml                    | 9 +++++++++
 src/backend/backup/basebackup_incremental.c | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 91da3c26ba..0f84ebc36e 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -925,6 +925,15 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/0
     to manage. For a large database all of which is heavily modified,
     incremental backups won't be much smaller than full backups.
    </para>
+
+   <para>
+    Like a base backup, you can take an incremental backup from a streaming
+    replication standby server.  But since a backup of a standby server cannot
+    initiate a checkpoint, it is possible that an incremental backup taken
+    right after a base backup will fail with an error, since it would have
+    to start with the same checkpoint as the base backup and would therefore
+    be empty.
+   </para>
   </sect2>
 
   <sect2 id="backup-lowlevel-base-backup">
diff --git a/src/backend/backup/basebackup_incremental.c b/src/backend/backup/basebackup_incremental.c
index 2108702397..85c16182a6 100644
--- a/src/backend/backup/basebackup_incremental.c
+++ b/src/backend/backup/basebackup_incremental.c
@@ -441,7 +441,8 @@ PrepareForIncrementalBackup(IncrementalBackupInfo *ib,
 						 errmsg("manifest requires WAL from final timeline %u ending at %X/%X, but this backup starts at %X/%X",
 								range->tli,
 								LSN_FORMAT_ARGS(range->end_lsn),
-								LSN_FORMAT_ARGS(backup_state->startpoint))));
+								LSN_FORMAT_ARGS(backup_state->startpoint)),
+						 errhint("Perhaps there was too little activity since the previous backup, and this incremental backup would be empty.")));
 		}
 		else
 		{
-- 
2.45.2

---

From: Michael Paquier <[email-masked]>
Date: Mon, 22 Jul 2024 15:05:50 +0900

> that WAL summarizing hasn't caught up yet.

Added an open item for this one.
--
Michael