From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Bug in brin_minmax_multi_distance_numeric()
Date: Thu, 31 Jul 2025 14:35:42 -0400
Message-ID: <2109935.1753986942@sss.pgh.pa.us> (raw)
In-Reply-To: <73006ea9-762d-4244-a63b-56bc91e3ba35@vondra.me>
References: <2093712.1753983215@sss.pgh.pa.us>
<73006ea9-762d-4244-a63b-56bc91e3ba35@vondra.me>
Tomas Vondra <tomas@vondra.me> writes:
> On 7/31/25 19:33, Tom Lane wrote:
>> ... 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.
Yeah, I'm not 100% sure about that. It's certainly doing something
unexpected, but we might accidentally end up with relatively-sane
relative distance comparisons anyway. (I assume the outputs will
only be compared to other outputs of the same function, right?)
I have a vague recollection that the IEEE float format was chosen with
an eye to making comparisons cheap, ie not too much different from
integer comparisons. So the sort order might be about the same
even after incorrectly reinterpreting the bit-pattern as an int.
NaNs probably mess that up, but they would anyway.
> 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.
Got it. So it might be worth reindexing such indexes after the
fix, but it's not strictly necessary.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, tomas@vondra.me, peter@eisentraut.org, pgsql-hackers@lists.postgresql.org
Subject: Re: Bug in brin_minmax_multi_distance_numeric()
In-Reply-To: <2109935.1753986942@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox