Bug in brin_minmax_multi_distance_numeric()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Peter Eisentraut <peter@eisentraut.org>,
pgsql-hackers@lists.postgresql.org
Date: 2025-07-31T17:33:35Z
Lists: pgsql-hackers
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. 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? regards, tom lane [1] https://www.postgresql.org/message-id/2091622.1753982274%40sss.pgh.pa.us
Commits
-
Fix incorrect return value in brin_minmax_multi_distance_numeric().
- b9279058a3ca 16.10 landed
- 9b681e239726 18.0 landed
- 835c9374d630 15.14 landed
- 80c758a2e1d7 19 (unreleased) landed
- 5b0c8e328949 14.19 landed
- 0b0d3c19bf07 17.6 landed