Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables

Hello,

I am following up on my report with a patch, which did not receive any responses. I suspect the issue only manifests under specific conditions, so I am sending additional details along with a reliable reproducer.



For context:

Incremental backups cannot be restored when a relation larger than 1 GB (multiple segments) is vacuum-truncated between the base backup and the incremental backup (pg_basebackup itself completes successfully, but the resulting incremental backup is not restorable)

For segmented relations, the WAL summarizer records limit_block in the WAL summary. During incremental backup, the truncation length is computed incorrectly because a relation-wide limit is compared against a segment-local size.



Reproducer

I am attaching a bash script that reliably reproduces the issue on my system. The script:

Creates a table large enough to span multiple segments.

Takes a full base backup.

Deletes rows at the end of the relation.

Runs VACUUM (TRUNCATE) to remove blocks.

Takes an incremental backup.

Fails during pg_combinebackup.

The script is fully automated and intended to be run as-is.

A patch itself in the previous message. 

I would appreciate feedback on the approach and am happy to revise it if needed.



Best regards,

Oleg Tkachenko



> On Nov 14, 2025, at 20:43, Oleg Tkachenko <oatkachenko@gmail.com> wrote:
> 
> Hello PostgreSQL developers,
> 
> I’ve encountered a bug in the incremental backup feature that prevents restoration of backups containing relations larger than 1 GB that were vacuum-truncated.
> 
> 
> 
> Problem Description
> 
> When taking incremental backups of relations that span multiple segments, if the relation is truncated during VACUUM (after the base backup but before the incremental one), pg_combinebackup fails with:
> 
> ```
> 
> file "%s" has truncation block length %u in excess of segment size %u
> 
> ```
> 
> pg_basebackup itself completes without errors, but the resulting incremental backup cannot be restored.
> 
> 
> 
> Root Cause
> 
> In segmented relations, a VACUUM that truncates blocks sets a limit_block in the WAL summary. The incremental restore logic miscalculates truncation_block_length when processing segment 0…N, because it compares the segment-local size with a relation-wide limit.
> 
> In src/backend/backup/basebackup_incremental.c:
> 
> ```
> 
> *truncation_block_length = size / BLCKSZ;
> 
> if (BlockNumberIsValid(limit_block))
> 
> {
> 
>     unsigned relative_limit = limit_block - segno * RELSEG_SIZE;
> 
>     if (*truncation_block_length < relative_limit)   /* ← problematic */
> 
>         *truncation_block_length = relative_limit;
> 
> }
> 
> ```
> 
> For example, if limit_block lies in segment 10, then relative_limit will be roughly 9 * RELSEG_SIZE while processing segment 0. This forces truncation_block_length far beyond the actual segment size, leading to a segment length larger than RELSEG_SIZE and eventually the restore error.
> 
> 
> 
> Reproduction Steps
> 
> 
> Create a table larger than 1 GB (multiple segments).
> 
> Take a full base backup.
> 
> Delete rows that occupy the end of the relation.
> 
> Run VACUUM (VERBOSE, TRUNCATE) to ensure blocks are removed.
> 
> (optional) Confirm that the WAL summary includes a limit entry for the relation.
> 
> Take an incremental backup with pg_basebackup.
> 
> Attempt to restore using pg_combinebackup.
> 
> Observe the truncation block length error.
> 
> 
> 
> 
> Patch
> 
> A patch correcting this logic is attached, and I’m happy to provide additional details or revisions if helpful.
> 
> 
> 
> Best regards,
> 
> Oleg Tkachenko
> 
> 
> <bug_truncation_block_length.patch>
> 
> 
> 
> 
>