- Notifications
You must be signed in to change notification settings - Fork4.9k
Commit6a33bb3
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 parentc05268e commit6a33bb3
1 file changed
+2
-2
lines changedLines changed: 2 additions & 2 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
773 | 773 |
| |
774 | 774 |
| |
775 | 775 |
| |
776 |
| - | |
| 776 | + | |
777 | 777 |
| |
778 | 778 |
| |
779 | 779 |
| |
| |||
817 | 817 |
| |
818 | 818 |
| |
819 | 819 |
| |
820 |
| - | |
| 820 | + | |
821 | 821 |
| |
822 | 822 |
| |
823 | 823 |
| |
|
0 commit comments
Comments
(0)