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_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/78721a206dc6123e47de17c522b650201de4ed0c Modified Files -------------- src/backend/access/brin/brin_minmax_multi.c | 40 ++++++++++++++++++++++++----- src/test/regress/expected/brin_multi.out | 10 ++++++++ src/test/regress/sql/brin_multi.sql | 14 ++++++++++ 3 files changed, 58 insertions(+), 6 deletions(-)
