mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-15 10:57:02 +08:00
c80b0c9d63
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