aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/ruleutils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-05-21 13:13:41 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-05-21 13:13:44 -0400
commita916cb9d5a89804998dd4e7fd7bbb27cb5a7abc8 (patch)
tree95fff229b2b404be908ad28ff2f9406aa1e3f497 /src/backend/utils/adt/ruleutils.c
parentac1ae477f85c6aeb3119071c1c00eb042b4afa4d (diff)
downloadpostgresql-a916cb9d5a89804998dd4e7fd7bbb27cb5a7abc8.tar.gz
postgresql-a916cb9d5a89804998dd4e7fd7bbb27cb5a7abc8.zip
Avoid overflow hazard when clamping group counts to "long int".
Several places in the planner tried to clamp a double value to fit in a "long" by doing (long) Min(x, (double) LONG_MAX); This is subtly incorrect, because it casts LONG_MAX to double and potentially back again. If long is 64 bits then the double value is inexact, and the platform might round it up to LONG_MAX+1 resulting in an overflow and an undesirably negative output. While it's not hard to rewrite the expression into a safe form, let's put it into a common function to reduce the risk of someone doing it wrong in future. In principle this is a bug fix, but since the problem could only manifest with group count estimates exceeding 2^63, it seems unlikely that anyone has actually hit this or will do so anytime soon. We're fixing it mainly to satisfy fuzzer-type tools. That being the case, a HEAD-only fix seems sufficient. Andrey Lepikhov Discussion: https://postgr.es/m/ebbc2efb-7ef9-bf2f-1ada-d6ec48f70e58@postgrespro.ru
Diffstat (limited to 'src/backend/utils/adt/ruleutils.c')
0 files changed, 0 insertions, 0 deletions