- Notifications
You must be signed in to change notification settings - Fork4.9k
Commitb296e55
committed
Avoid integer overflow while testing wal_skip_threshold condition.
smgrDoPendingSyncs had two distinct risks of integer overflow whiledeciding which way to ensure durability of a newly-created relation.First, it accumulated the total size of all forks in a variable oftype BlockNumber (uint32). While we restrict an individual fork'ssize to fit in that, I don't believe there's such a restriction onall of them added together. Second, it proceeded to multiply thesum by BLCKSZ, which most certainly could overflow a uint32.(The exact expression is total_blocks * BLCKSZ / 1024. Thecompiler might choose to optimize that to total_blocks * 8,which is not at quite as much risk of overflow as a literalreading would be, but it's still wrong.)If an overflow did occur it could lead to a poor choice toshove a very large relation into WAL instead of fsync'ing it.This wouldn't be fatal, but it could be inefficient.Change total_blocks to uint64 which should be plenty, andrearrange the comparison calculation to be overflow-safe.I noticed this while looking for ramifications of the proposedchange in MAX_KILOBYTES. It's not entirely clear to me whywal_skip_threshold is limited to MAX_KILOBYTES in thefirst place, but in any case this code is unsafe regardlessof the range of wal_skip_threshold.Oversight inc6b9204 which introduced wal_skip_threshold,so back-patch to v13.Discussion:https://postgr.es/m/1a01f0-66ec2d80-3b-68487680@27595217Backpatch-through: 131 parentbb85d09 commitb296e55
1 file changed
+2
-2
lines changedLines changed: 2 additions & 2 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
780 | 780 |
| |
781 | 781 |
| |
782 | 782 |
| |
783 |
| - | |
| 783 | + | |
784 | 784 |
| |
785 | 785 |
| |
786 | 786 |
| |
| |||
824 | 824 |
| |
825 | 825 |
| |
826 | 826 |
| |
827 |
| - | |
| 827 | + | |
828 | 828 |
| |
829 | 829 |
| |
830 | 830 |
| |
|
0 commit comments
Comments
(0)