Re: Fix BRIN numeric_minmax_multi_ops out of range value range merging

On 10/27/26 19:59, Kirill Reshke wrote:
> Hi
> While reviewing some reports in pgsql-bugs I bumped into simple SQL
> reproduced of BRIN out of range issue
>
> CREATE TABLE t (n numeric);
> INSERT INTO t VALUES (1), (1e1000);
> CREATE INDEX ON t USING brin (n numeric_minmax_multi_ops);
>
> This fails. brin_minmax_multi_distance_numeric computes heuristic, so
> it can be approximated. Patch uses numeric_sub_safe with an
> ErrorSaveContext and returns inf if any error occurred (which can only
> be an overflow in current code base, see make_result_safe)
>
> The numeric-distance overflow risk was discussed during the original
> minmax-multi development in 2018 [0], with normalizing value into 0-1
> range. I didn't fix that way, the issue fixed in the current
> implementation.
>

Thanks for the report. I'll take a closer look at the fix, but it seems
like the right approach to me.

I wonder if we need to do anything for the other distance functions.
Those can't fail like this, because the subtraction happens without a
function call (or a check). AFAICS it should not lead to bug/failure,
except maybe inefficient index.

But overflows are undefined behavior (at least for the integer types),
so maybe we should do something about it anyway.

regards

--
Tomas Vondra