]> git.ipfire.org Git - thirdparty/postgresql.git/commit
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:48 +0000 (12:09 -0500)
commitc80b0c9d63b25a1e7fc751a4cf66a6510ffafbb8
tree0f8f3d42889517dff92d6710273979a97ea1152f
parent7650eabb662f2f3708042c0b713c46aa042db94f
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]