Fix overflow when calculating timestamp distance in BRIN
When calculating distances for timestamp values for BRIN minmax-multi
indexes, we need to be careful about overflows for extreme values. If
the value overflows into a negative value, the index may be inefficient.
The new regression test checks this for the timestamp type by adding a
table with enough values to force range compaction/merging. The values
are close to min/max, which means a risk of overflow.
Fixed by converting the int64 values to double first, before calculating
the distance. This prevents the overflow. We may lose some precision, of
course, but that's good enough. In the worst case we build a slightly
less efficient index, but for large distances this won't matter.
This only affects minmax-multi indexes on timestamp columns, with ranges
containing values sufficiently distant to cause an overflow. That seems
like a fairly rare case in practice.
Backpatch to 14, where minmax-multi indexes were introduced.
Reported-by: Ashutosh Bapat
Reviewed-by: Ashutosh Bapat, Dean Rasheed
Backpatch-through: 14
Discussion: https://postgr.es/m/eef0ea8c-4aaa-8d0d-027f-58b1f35dd170@enterprisedb.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/b5489b75c6ce9517ab5f9d6f1d98bc928f6d5bd5
Modified Files
--------------
src/backend/access/brin/brin_minmax_multi.c | 2 +-
src/test/regress/expected/brin_multi.out | 15 +++++++++++++++
src/test/regress/sql/brin_multi.sql | 21 +++++++++++++++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
