Обсуждение: [BUG] pg_basebackup produces wrong incremental files after relation truncation in segmented tables

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

1. Create a table larger than 1 GB (multiple segments).

2. Take a full base backup.

3. Delete rows that occupy the end of the relation.

4. Run VACUUM (VERBOSE, TRUNCATE) to ensure blocks are removed.

5. (optional) Confirm that the WAL summary includes a limit entry for the relation.

6. Take an incremental backup with pg_basebackup.

7. Attempt to restore using pg_combinebackup.

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

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:

1. Creates a table large enough to span multiple segments.

2. Takes a full base backup.

3. Deletes rows at the end of the relation.

4. Runs VACUUM (TRUNCATE) to remove blocks.

5. Takes an incremental backup.

6. 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 Mon, Dec 15, 2025 at 4:39 PM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
>
>  [....]
>
> A patch correcting this logic is attached, and I’m happy to provide additional details or revisions if helpful.
>

Thanks for the reproducer; I can see the reported issue, but I am not
quite sure the proposed fix is correct and might break other cases (I
haven't tried constructed that case yet) but there is a comment
detailing that case just before the point where you are planning to do
the changes:

    /*
     * The truncation block length is the minimum length of the reconstructed
     * file. Any block numbers below this threshold that are not present in
     * the backup need to be fetched from the prior backup. At or above this
     * threshold, blocks should only be included in the result if they are
     * present in the backup. (This may require inserting zero blocks if the
     * blocks included in the backup are non-consecutive.)
     */

IIUC, we might need the original assignment logic as it is. But we
need to ensure that truncation_block_length is not set to a value that
exceeds RELSEG_SIZE.

Regards,
Amul

[ sorry for not noticing this thread sooner; thanks to Andres for
pointing me to it ]

On Mon, Dec 15, 2025 at 9:01 AM Amul Sul <sulamul@gmail.com> wrote:
> Thanks for the reproducer; I can see the reported issue, but I am not
> quite sure the proposed fix is correct and might break other cases (I
> haven't tried constructed that case yet) but there is a comment
> detailing that case just before the point where you are planning to do
> the changes:
>
>     /*
>      * The truncation block length is the minimum length of the reconstructed
>      * file. Any block numbers below this threshold that are not present in
>      * the backup need to be fetched from the prior backup. At or above this
>      * threshold, blocks should only be included in the result if they are
>      * present in the backup. (This may require inserting zero blocks if the
>      * blocks included in the backup are non-consecutive.)
>      */
>
> IIUC, we might need the original assignment logic as it is. But we
> need to ensure that truncation_block_length is not set to a value that
> exceeds RELSEG_SIZE.

I think you're right. By way of example, let's say that the current
length of the file is 200 blocks, but the limit block is 100 blocks
into the current segment. That means that the only blocks that we can
get from any previous backup are blocks 0-99. Blocks 100-199 of the
current segment are either mentioned in the WAL summaries we're using
for this backup, or they're all zeroes. We can't set the
truncation_block_length to a value greater than 100, or we'll go
looking for the contents of any zero-filled blocks in previous
backups, will will either fail or produce the wrong answer. But Oleg
is correct that we also shouldn't set it to a value greater than
RELSEG_SIZE. So my guess is that the correct fix might be something
like the attached (untested, for discussion).

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

On Mon, Dec 15, 2025 at 1:46 PM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
> Also, I’ve attached a patch based on your guidance. The changes are effectively the same as your suggested approach,
butI would be happy to be listed as a contributor. 

You'll certain be listed as the reporter for this issue when a fix is
committed. If you want to be listed as a co-author of the patch, I
think it is fair to say that it will need to contain some code written
by you. For example, maybe you would like to try writing a TAP test
case that fails without this fix and passes with it.

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

> On Dec 16, 2025, at 00:35, Robert Haas <robertmhaas@gmail.com> wrote:
>
> [ sorry for not noticing this thread sooner; thanks to Andres for
> pointing me to it ]
>
> On Mon, Dec 15, 2025 at 9:01 AM Amul Sul <sulamul@gmail.com> wrote:
>> Thanks for the reproducer; I can see the reported issue, but I am not
>> quite sure the proposed fix is correct and might break other cases (I
>> haven't tried constructed that case yet) but there is a comment
>> detailing that case just before the point where you are planning to do
>> the changes:
>>
>>    /*
>>     * The truncation block length is the minimum length of the reconstructed
>>     * file. Any block numbers below this threshold that are not present in
>>     * the backup need to be fetched from the prior backup. At or above this
>>     * threshold, blocks should only be included in the result if they are
>>     * present in the backup. (This may require inserting zero blocks if the
>>     * blocks included in the backup are non-consecutive.)
>>     */
>>
>> IIUC, we might need the original assignment logic as it is. But we
>> need to ensure that truncation_block_length is not set to a value that
>> exceeds RELSEG_SIZE.
>
> I think you're right. By way of example, let's say that the current
> length of the file is 200 blocks, but the limit block is 100 blocks
> into the current segment. That means that the only blocks that we can
> get from any previous backup are blocks 0-99. Blocks 100-199 of the
> current segment are either mentioned in the WAL summaries we're using
> for this backup, or they're all zeroes. We can't set the
> truncation_block_length to a value greater than 100, or we'll go
> looking for the contents of any zero-filled blocks in previous
> backups, will will either fail or produce the wrong answer. But Oleg
> is correct that we also shouldn't set it to a value greater than
> RELSEG_SIZE. So my guess is that the correct fix might be something
> like the attached (untested, for discussion).
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
> <v1-0001-Don-t-set-the-truncation_block_length-rather-than.patch>


The change looks good to me. Only nitpick is:

```
Subject: [PATCH v1] Don't set the truncation_block_length rather than
 RELSEG_SIZE.
```

I guess you meant to say “larger (or greater) than” instead of “rather than”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/