aboutsummaryrefslogtreecommitdiff
path: root/src/backend/storage/file/reinit.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-12-19 11:12:16 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2023-12-19 11:12:16 -0500
commit7e1ce2b3de16dfbe1598cef060dfc8458522938a (patch)
treea0a5fe0eda7b6791d808f16ded3ae0b1af1175c8 /src/backend/storage/file/reinit.c
parent2a607fb822a2ad8f3a2cc714871283ad8cdf71c4 (diff)
downloadpostgresql-7e1ce2b3de16dfbe1598cef060dfc8458522938a.tar.gz
postgresql-7e1ce2b3de16dfbe1598cef060dfc8458522938a.zip
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
Diffstat (limited to 'src/backend/storage/file/reinit.c')
0 files changed, 0 insertions, 0 deletions