Prevent integer overflow when forming tuple width estimates.
It's at least theoretically possible to overflow int32 when adding up
column width estimates to make a row width estimate. (The bug example
isn't terribly convincing as a real use-case, but perhaps wide joins
would provide a more plausible route to trouble.) This'd lead to
assertion failures or silly planner behavior. To forestall it, make
the relevant functions compute their running sums in int64 arithmetic
and then clamp to int32 range at the end. We can reasonably assume
that MaxAllocSize is a hard limit on actual tuple width, so clamping
to that is simply a correction for dubious input values, and there's
no need to go as far as widening width variables to int64 everywhere.
Per bug #18247 from RekGRpth. There've been no reports of this issue
arising in practical cases, so I feel no need to back-patch.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/18247-11ac477f02954422@postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/7e1ce2b3de16dfbe1598cef060dfc8458522938a
Modified Files
--------------
src/backend/optimizer/path/costsize.c | 43 ++++++++++++++++++++++++++------
src/backend/optimizer/plan/planner.c | 4 ++-
src/backend/optimizer/util/placeholder.c | 5 +++-
src/backend/optimizer/util/plancat.c | 4 +--
src/backend/optimizer/util/relnode.c | 10 +++++---
src/include/optimizer/optimizer.h | 1 +
6 files changed, 52 insertions(+), 15 deletions(-)