Handle numeric overflow in numeric_minmax_multi_ops When calculating the distance between numeric values, the code could overflow in two ways. A subtraction of two finite values may still overflow, or the result may not fit into float8.
The distances don't need to be perfectly accurate, although it may make the index less efficient. And for most minmax-multi opclasses it works like that, but for numeric the functions may error-out. That prevents summarization, either when creating an index or later during vacuum. Fix by using numeric_sub_safe() and numeric_float8_no_overflow(), and returning infinity when either of those fails. The older releases need to use numeric_sub_opt_error(), but the principle is the same. Also, handle NaN values the same as for float4/float8. When both values are NaN, return distance 0. When one value is NaN, return infinity. While at it, free the detoasted copies of arguments, and the calculated numeric distance. For small values it does not matter, but for extreme numeric values it may make a difference. Reported by Kirill Reshke, with a patch fixing the issue. Various improvements and backpatching by me. Backpatch to 14, where minmax-multi indexes were introduced. Author: Kirill Reshke <[email protected]> Author: Tomas Vondra <[email protected]> Reviewed-by: shihao zhong <[email protected]> Backpatch-through: 14 Discussion: https://postgr.es/m/CALdSSPgBvXz-VSF0p-5k%3D_uFfN38cWrERmm_AC4K67N6MWQhmg%40mail.gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b8d5b9a0115f531f1a4627a2e4f97ea04ae906b9 Modified Files -------------- src/backend/access/brin/brin_minmax_multi.c | 38 ++++++++++++++++++++++++----- src/test/regress/expected/brin_multi.out | 10 ++++++++ src/test/regress/sql/brin_multi.sql | 14 +++++++++++ 3 files changed, 56 insertions(+), 6 deletions(-)
