From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Bug in brin_minmax_multi_distance_numeric() |
Date: | 2025-07-31 17:33:35 |
Message-ID: | 2093712.1753983215@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-07-31 18:22:38 | Re: Non-text mode for pg_dumpall |
Previous Message | Tom Lane | 2025-07-31 17:17:54 | Re: Datum as struct |