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-58b1f35dd...@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(-)