Re: Bug in brin_minmax_multi_distance_numeric()

On 7/31/25 19:33, Tom Lane wrote:
> Per the discussion in [1], I think we need something like
> 
> -	PG_RETURN_FLOAT8(DirectFunctionCall1(numeric_float8, d));
> +	PG_RETURN_DATUM(DirectFunctionCall1(numeric_float8, d));
> 
> in brin_minmax_multi_distance_numeric().  Peter was proposing
> that as cosmetic cleanup, but I think it's actually a functional
> bug that needs to be back-patched.  It is certainly broken on
> 32-bit machines where the Datum result of numeric_float8 will
> be a pointer, so that we will convert the numeric pointer value
> to a float and return that, yielding a totally-garbage distance
> value.  But I think it's broken on 64-bit machines too, because
> we'll be interpreting the output of numeric_float8 as a uintptr_t
> and applying some unwanted conversion to make that a float.
> 

Agreed it's a bug on 32-bit machines. Not sure about 64-bits.


> It's not clear to me exactly what this function is used for,
> but I guess the consequences would be broken BRIN indexes
> on numeric columns?
> 

Actually, no - it should not cause "broken" indexes, as in "giving
incorrect results". The distance functions determine in what order we
merge points into ranges, and if the distances are bogus then we can
build a summary that is less efficient.


regards

-- 
Tomas Vondra