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

Поиск
Список
Период
Сортировка
От Oleg Tkachenko
Тема Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
Дата
Msg-id F687B661-E975-4383-8A94-F9130FE7ACC1@gmail.com
обсуждение исходный текст
Ответ на [BUG] pg_basebackup produces wrong incremental files after relation truncation in segmented tables  (Oleg Tkachenko <oatkachenko@gmail.com>)
Ответы Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
Список pgsql-hackers

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


  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


<bug_truncation_block_length.patch>




Вложения

В списке pgsql-hackers по дате отправления: