From: Oleg Tkachenko <oatkachenko@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files
 after relation truncation in segmented tables
In-Reply-To: <CA+Tgmob2j58xsksWMPHfyXBMq4go4qKWyMJWeE6QUugLp6hVXQ@mail.gmail.com>
Date: Wed, 7 Jan 2026 15:49:56 +0100
Cc: Amul Sul <sulamul@gmail.com>,
 pgsql-hackers@lists.postgresql.org,
 Stanislav Bashkyrtsev <stanislav.bashkyrtsev@elsci.io>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6897DAF7-B699-41BF-A6FB-B818FCFFD585@gmail.com>
References: <00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com>
 <F687B661-E975-4383-8A94-F9130FE7ACC1@gmail.com>
 <CAAJ_b94y98BWWgf0KMw-E_pqM_y8+RogqHtu5nK0kA1uBE3WWw@mail.gmail.com>
 <CA+TgmoZ7LQ40tLGpHw0U51CReH_8jv0sO0dALGRJp=FT+ZtGFQ@mail.gmail.com>
 <22474984-C4CD-4300-A84E-C1CA58F61CDA@gmail.com>
 <CA+TgmobbxO26OcYcruA=qjSfKeQRzEF_n3_Ljs9ts1MTzCSWxg@mail.gmail.com>
 <A4159D9E-C980-4782-9B91-4B41410AE374@gmail.com>
 <CAAJ_b95v6Kbby_YkBbvAgdujEM7uD7YCTCa62upSZjexsZ8qgw@mail.gmail.com>
 <CA+Tgmoa6aSg-zNDs6F9FtFrjrCozt0_32yQkom9BZsLi-REWAA@mail.gmail.com>
 <08EA8874-0114-4E5C-A794-EB40C971EE7C@gmail.com>
 <CA+Tgmob2j58xsksWMPHfyXBMq4go4qKWyMJWeE6QUugLp6hVXQ@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/6897DAF7-B699-41BF-A6FB-B818FCFFD585%40gmail.com>
Precedence: bulk

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)
                                   ^^^^  ^^^^=20
```

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.=20
So I checked the WAL files to see what really happened with the VM fork.
I did not find any =E2=80=9Ctruncate" records for the VM file.
I only found this record for the main fork=20
(actually, the fork isn=E2=80=99t 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 =3D=3D 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:
>=20
> On Thu, Dec 18, 2025 at 12:24=E2=80=AFPM Oleg Tkachenko =
<oatkachenko@gmail.com> wrote:
>> Here is a refactored test.
>>=20
>> Now, it creates data depending on the relation block size, so it =
works even if the segment size is not standard. I tested it locally with =
segment_size_blocks =3D 6, and it works correctly.
>>=20
>> I would be happy to hear your comments or suggestions.
>=20
> Hi Oleg,
>=20
> 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:
>=20
> pg_combinebackup: reconstructing
> =
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_t=
runcation_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_da=
ta/backup/full/base/5/16384.1@0
> pg_combinebackup: read 1 blocks from
> =
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_t=
runcation_block/data/t_050_incremental_backup_truncation_block_primary_dat=
a/backup/full/base/5/16384.1"
> pg_combinebackup: reconstructing
> =
"/tmp/cirrus-ci-build/build/testrun/pg_basebackup/050_incremental_backup_t=
runcation_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_backu=
p_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_da=
ta/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_t=
runcation_block/data/t_050_incremental_backup_truncation_block_node2_data/=
pgdata/base/5/16384_vm":
> No space left on device
>=20
> 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?
>=20
> 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.
>=20
> --=20
> Robert Haas
> EDB: http://www.enterprisedb.com