From bac3a98cd4e4b3007e140d9db334b040cf6772c5 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Mon, 15 Dec 2025 11:34:34 -0500 Subject: [PATCH v1] Don't set the truncation_block_length rather than RELSEG_SIZE. Also, add some comments to explain the logic. --- src/backend/backup/basebackup_incremental.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/backup/basebackup_incremental.c b/src/backend/backup/basebackup_incremental.c index 7678e4f6ec3..f4ef33f6672 100644 --- a/src/backend/backup/basebackup_incremental.c +++ b/src/backend/backup/basebackup_incremental.c @@ -850,8 +850,22 @@ GetFileBackupMethod(IncrementalBackupInfo *ib, const char *path, { unsigned relative_limit = limit_block - segno * RELSEG_SIZE; + /* + * We can't set a truncation_block_length in excess of the limit block + * number (relativized to the current segment). To do so would be to + * treat blocks from older backups as valid current contents even if + * they were subsequently truncated away. + */ if (*truncation_block_length < relative_limit) *truncation_block_length = relative_limit; + + /* + * We also can't set a truncation_block_length in excess of the + * segment size, since the reconstructed file can't be larger than + * that. + */ + if (*truncation_block_length > RELSEG_SIZE) + *truncation_block_length = RELSEG_SIZE; } /* Send it incrementally. */ -- 2.51.0