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_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/174b605f0e3a3e6a01a137ea401733b699937cad 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(-)
