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 <[email protected]> Diagnosed-by: Oleg Tkachenko <[email protected]> Co-authored-by: Robert Haas <[email protected]> Co-authored-by: Oleg Tkachenko <[email protected]> Reviewed-by: Amul Sul <[email protected]> Backpatch-through: 17 Discussion: http://postgr.es/m/[email protected] Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ecd275718be0908c8f5af871d28052e7e71c729e Modified Files -------------- src/backend/backup/basebackup_incremental.c | 14 +++ src/bin/pg_combinebackup/meson.build | 1 + .../t/011_incremental_backup_truncation_block.pl | 101 +++++++++++++++++++++ 3 files changed, 116 insertions(+)
