git.postgresql.org Git - postgresql.git/commit

git projects / postgresql.git / commit
? search:
summary | shortlog | log | commit | commitdiff | tree
(parent: ac1ae47) | patch
Avoid overflow hazard when clamping group counts to "long int".
2022年5月21日 17:13:41 +0000 (13:13 -0400)
2022年5月21日 17:13:44 +0000 (13:13 -0400)
commit a916cb9d5a89804998dd4e7fd7bbb27cb5a7abc8
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
src/backend/executor/nodeSubplan.c diff | blob | blame | history
src/backend/optimizer/path/costsize.c diff | blob | blame | history
src/backend/optimizer/plan/createplan.c diff | blob | blame | history
src/include/optimizer/optimizer.h diff | blob | blame | history
This is the main PostgreSQL git repository.
RSS Atom

AltStyle によって変換されたページ (->オリジナル) /