diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-12-19 11:12:16 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-12-19 11:12:16 -0500 |
| commit | 7e1ce2b3de16dfbe1598cef060dfc8458522938a (patch) | |
| tree | a0a5fe0eda7b6791d808f16ded3ae0b1af1175c8 /src/include/optimizer/optimizer.h | |
| parent | 2a607fb822a2ad8f3a2cc714871283ad8cdf71c4 (diff) | |
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/include/optimizer/optimizer.h')
| -rw-r--r-- | src/include/optimizer/optimizer.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/src/include/optimizer/optimizer.h b/src/include/optimizer/optimizer.h index 6e8b81c51d5..da50044bf14 100644 --- a/src/include/optimizer/optimizer.h +++ b/src/include/optimizer/optimizer.h @@ -90,6 +90,7 @@ extern PGDLLIMPORT double recursive_worktable_factor; extern PGDLLIMPORT int effective_cache_size; extern double clamp_row_est(double nrows); +extern int32 clamp_width_est(int64 tuple_width); extern long clamp_cardinality_to_long(Cardinality x); /* in path/indxpath.c: */ |