On Wed, 2024-07-24 at 15:27 -0400, Robert Haas wrote: > On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote: > > An incremental backup is only possible if replay would begin from a later > > checkpoint than the checkpoint that started the previous backup upon > > which > > it depends. > > My concern here is that the previous backup might have been taken on a > standby, and therefore it did not start with a checkpoint. For a > standby backup, replay will begin from a checkpoint record, but that > record may be quite a bit earlier in the WAL. For instance, imagine > checkpoint_timeout is set to 30 minutes on the standby. When the > backup is taken, the most recent restartpoint could be up to 30 > minutes ago -- and it is the checkpoint record for that restartpoint > from which replay will begin. I think that in my phrasing, it's always > about the checkpoint from which replay would begin (which is always > well-defined) not the checkpoint that started the backup (which is > only logical on the primary).
I see. The attached patch uses your wording for the first sentence. I left out the last sentence from your suggestion, because it sounded like it is likely to confuse the reader. I think you just wanted to say that there are other possible causes for an incremental backup to fail. I want to keep the text as simple as possible and focus on the case that I hit, because I expect that a lot of people who experiment with incremental backup or run tests could run into the same problem. I don't think it will be a frequent occurrence during normal operation. Yours, Laurenz Albe
From 1a570da7e93b81c7be488fcc4e0ff3a283320923 Mon Sep 17 00:00:00 2001 From: Laurenz Albe <laurenz.a...@cybertec.at> Date: Thu, 25 Jul 2024 14:44:27 +0200 Subject: [PATCH v3] Document an error with incremental backup on standbys Taking an incremental backup on a streaming replication standby immediately after the previous backup 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/04f4277e5ed4046773e46837110bed1381a2583f.ca...@cybertec.at Backpatch to v17. --- doc/src/sgml/backup.sgml | 11 +++++++++++ src/backend/backup/basebackup_incremental.c | 3 ++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 91da3c26ba..e4e4c56cf1 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -925,6 +925,17 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && 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> + An incremental backup is only possible if replay would begin from a later + checkpoint than for the previous backup upon which it depends. If you + take the incremental backup on the primary, this condition is always + satisfied, because each backup triggers a new checkpoint. On a standby, + replay begins from the most recent restartpoint. Therefore, an + incremental backup of a standby server can fail if there has been very + little activity since the previous backup, since no new restartpoint might + have been created. + </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..a023e62440 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("This can happen for incremental backups on a standby if there was little activity since the previous backup."))); } else { -- 2.45.2
