Don't set the truncation block length greater than RELSEG_SIZE.
authorRobert Haas <rhaas@postgresql.org>
Mon, 19 Jan 2026 17:02:08 +0000 (12:02 -0500)
committerRobert Haas <rhaas@postgresql.org>
Mon, 19 Jan 2026 17:09:32 +0000 (12:09 -0500)
commitecd275718be0908c8f5af871d28052e7e71c729e
tree0d2f66c0cc0921f7f29909c07a74a73d38e69236
parent34740b90bc123d645a3a71231b765b778bdcf049
Don't set the truncation block length greater than RELSEG_SIZE.

When faced with a relation containing more than 1 physical segment
(i.e. >1GB, with normal settings), the previous code could compute a
truncation block length greater than RELSEG_SIZE, which could lead to
restore failures of this form:

file "%s" has truncation block length %u in excess of segment size %u

The fix is simply to clamp the maximum computed truncation_block_length
to RELSEG_SiZE. I have also added some comments to clarify the logic.

The test case was written by Oleg Tkachenko, but I have rewritten its
comments.

Reported-by: Oleg Tkachenko <oatkachenko@gmail.com>
Diagnosed-by: Oleg Tkachenko <oatkachenko@gmail.com>
Co-authored-by: Robert Haas <rhaas@postgresql.org>
Co-authored-by: Oleg Tkachenko <oatkachenko@gmail.com>
Reviewed-by: Amul Sul <sulamul@gmail.com>
Backpatch-through: 17
Discussion: http://postgr.es/m/00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com
src/backend/backup/basebackup_incremental.c
src/bin/pg_combinebackup/meson.build
src/bin/pg_combinebackup/t/011_incremental_backup_truncation_block.pl [new file with mode: 0644]