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
