Fix BRIN minmax-multi distance for interval type

tvondra · tvondra · commit 2b10e0e3c2ca · 2021-04-04T19:19:51.000+02:00
The distance calculation for interval type was treating months as having 31 days, which is inconsistent with the interval comparator (using 30 days). Due to this it was possible to get negative distance (b-a) when (a<b), trigerring an assert. Fixed by adopting the same logic as interval_cmp_value. Reported-by: Jaime Casanova Discussion: https://postgr.es/m/CAJKUy5jKH0Xhneau2mNftNPtTy-BVgQfXc8zQkEvRvBHfeUThQ%40mail.gmail.com
diff --git a/src/backend/access/brin/brin_minmax_multi.c b/src/backend/access/brin/brin_minmax_multi.c
@@ -2127,6 +2127,9 @@ brin_minmax_multi_distance_interval(PG_FUNCTION_ARGS)
 	Interval   *ib = PG_GETARG_INTERVAL_P(1);
 	Interval   *result;
 
+	int64		dayfraction;
+	int64		days;
+
 	result = (Interval *) palloc(sizeof(Interval));
 
 	result->month = ib->month - ia->month;
@@ -2152,16 +2155,18 @@ brin_minmax_multi_distance_interval(PG_FUNCTION_ARGS)
 				 errmsg("interval out of range")));
 
 	/*
-	 * We assume months have 31 days - we don't need to be precise, in the
-	 * worst case we'll build somewhat less efficient ranges.
+	 * Delta is (fractional) number of days between the intervals. Assume
+	 * months have 30 days for consistency with interval_cmp_internal.
+	 * We don't need to be exact, in the worst case we'll build a bit less
+	 * efficient ranges. But we should not contradict interval_cmp.
 	 */
-	delta = (float8) (result->month * 31 + result->day);
-
-	/* convert to microseconds (just like the time part) */
-	delta = 24L * 3600L * delta;
+	dayfraction = result->time % USECS_PER_DAY;
+	days = result->time / USECS_PER_DAY;
+	days += result->month * INT64CONST(30);
+	days += result->day;
 
-	/* and add the time part */
-	delta += result->time / (float8) 1000000.0;
+	/* convert to double precision */
+	delta = (double) days + dayfraction / (double) USECS_PER_DAY;
 
 	Assert(delta >= 0);
 
