pgsql: Fix incorrect return value in brin_minmax_multi_distance_numeric - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix incorrect return value in brin_minmax_multi_distance_numeric
Date
Msg-id E1ujOd6-000vkg-1r@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix incorrect return value in brin_minmax_multi_distance_numeric().

The result of "DirectFunctionCall1(numeric_float8, d)" is already in
Datum form, but the code was incorrectly applying PG_RETURN_FLOAT8()
to it.  On machines where float8 is pass-by-reference, this would
result in complete garbage, since an unpredictable pointer value
would be treated as an integer and then converted to float.  It's not
entirely clear how much of a problem would ensue on 64-bit hardware,
but certainly interpreting a float8 bitpattern as uint64 and then
converting that to float isn't the intended behavior.

As luck would have it, even the complete-garbage case doesn't break
BRIN indexes, since the results are only used to make choices about
how to merge values into ranges: at worst, we'd make poor choices
resulting in an inefficient index.  Doubtless that explains the lack
of field complaints.  However, users with BRIN indexes that use the
numeric_minmax_multi_ops opclass may wish to reindex in hopes of
making their indexes more efficient.

Author: Peter Eisentraut <peter@eisentraut.org>
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/2093712.1753983215@sss.pgh.pa.us
Backpatch-through: 14

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/b9279058a3ca416e42dd73a54c426c8e43f6c8ca

Modified Files
--------------
src/backend/access/brin/brin_minmax_multi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


pgsql-committers by date:

Previous
From: Álvaro Herrera
Date:
Subject: pgsql: Put PG_TEST_EXTRA doc items back in alphabetical order
Next
From: Masahiko Sawada
Date:
Subject: pgsql: Suppress maybe-uninitialized warning.