pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Don't set the truncation block length greater than RELSEG_SIZE. 3+ messages / 1 participants [nested] [flat]
* pgsql: Don't set the truncation block length greater than RELSEG_SIZE. @ 2026-01-19 17:41 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Robert Haas @ 2026-01-19 17:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ad569b54a1064d8f9e787f5fe72995002b37c106 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(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Don't set the truncation block length greater than RELSEG_SIZE. @ 2026-01-19 17:41 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Robert Haas @ 2026-01-19 17:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 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(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Don't set the truncation block length greater than RELSEG_SIZE. @ 2026-01-19 17:41 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 3+ messages in thread From: Robert Haas @ 2026-01-19 17:41 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c80b0c9d63b25a1e7fc751a4cf66a6510ffafbb8 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(+) ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-01-19 17:41 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-19 17:41 pgsql: Don't set the truncation block length greater than RELSEG_SIZE. Robert Haas <rhaas@postgresql.org> 2026-01-19 17:41 pgsql: Don't set the truncation block length greater than RELSEG_SIZE. Robert Haas <rhaas@postgresql.org> 2026-01-19 17:41 pgsql: Don't set the truncation block length greater than RELSEG_SIZE. Robert Haas <rhaas@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox