Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables - Mailing list pgsql-hackers

Hello Robert,

I checked the VM fork file and found that its incremental version has a wrong
block number in the header:

```
xxd -l 12 INCREMENTAL.16384_vm
0d1f aed3 0100 0000 0000 0200  <--- 131072 blocks (1 GB)
                                   ^^^^  ^^^^
```

This value can only come from the WAL summaries, so I checked them too.
One of the summary files contains:

```
TS 1663, DB 5, REL 16384, FORK main: limit 131073
TS 1663, DB 5, REL 16384, FORK vm: limit 131073
TS 1663, DB 5, REL 16384, FORK vm: block 4

```

Both forks have the same limit, which looks wrong.
So I checked the WAL files to see what really happened with the VM fork.
I did not find any “truncate" records for the VM file.
I only found this record for the main fork
(actually, the fork isn’t mentioned at all):

```
rmgr: Storage  len (rec/tot): 46/46, tx: 759, lsn: 0/4600D318,
 prev 0/4600B2C8, desc: TRUNCATE base/5/16384 to 131073 blocks flags 7
```

This suggests that the WAL summarizer may be mixing up information between
relation forks.

I also noticed this comment in basebackup_incremental.c:

```
/*
* The free-space map fork is not properly WAL-logged, so we need to
* backup the entire file every time.
*/
if (forknum == FSM_FORKNUM)
    return BACK_UP_FILE_FULLY;
```

Maybe we should treat the VM fork the same way and always back it up fully?
Another option is to fix the summarizer so it handles forks correctly.

Best regards,
Oleg

> On Jan 5, 2026, at 17:05, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Dec 18, 2025 at 12:24 PM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
>> Here is a refactored test.
>>
>> Now, it creates data depending on the relation block size, so it works even if the segment size is not standard. I
testedit locally with segment_size_blocks = 6, and it works correctly. 
>>
>> I would be happy to hear your comments or suggestions.
>
> Hi Oleg,
>
> I have been mostly on vacation since you sent this email, but here I
> am back again. I tried running this on CI with and without the actual
> code fix, and was pleased to see the CI failed on this test without
> the code fix and passed with it. But then I noticed that you hadn't
> updated meson.build in src/bin/pg_basebackup for the new test, which
> means that the test was only running in configure/make builds and not
> in meson/ninja builds. When I fixed that, things didn't look so good.
> The test then fails:
>
> pg_combinebackup: reconstructing
>
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_node2_data/pgdata/base/5/16384.1"
> (1 blocks, checksum CRC32C)
> pg_combinebackup: reconstruction plan:
>
0:/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_primary_data/backup/full/base/5/16384.1@0
> pg_combinebackup: read 1 blocks from
>
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_primary_data/backup/full/base/5/16384.1"
> pg_combinebackup: reconstructing
>
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_node2_data/pgdata/base/5/16384_vm"
> (131072 blocks, checksum CRC32C)
> pg_combinebackup: reconstruction plan:
>
0-3:/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_primary_data/backup/full/base/5/16384_vm@24576
>
4:/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_primary_data/backup/incr/base/5/INCREMENTAL.16384_vm@8192
> 5-131071:zero
> pg_combinebackup: error: could not write file
>
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_truncation_block/data/t_050_incremental_backup_truncation_block_node2_data/pgdata/base/5/16384_vm":
> No space left on device
>
> I'm not sure what's going on here exactly, but it seems bad. The
> output implies that 16384_vm is a full 1GB in size, which doesn't
> really make any sense to me at all, but the same thing also happens
> when I run the test locally. The VM fork is normally quite small
> compared to the data, and here the data is only one block over 1GB, so
> I'd expect the VM fork to be just a few blocks. Are we somehow
> confusing the length of the VM fork with the length of the main fork?
>
> A couple of stylistic notes: All of the existing incremental backup
> tests are in src/bin/pg_combinebackup/t. I suggest putting this one
> there too. Normally, our TAP test names are all lower-case, so do the
> same here. Try to format the test file so that things fit within 80
> columns, by breaking comments and Perl statements at appropriate
> points. Consider running src/tools/pgindent/pgperltidy over the script
> to check that the way you've broken the Perl statements won't get
> reindented.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com