Re: BRIN minmax multi - incorrect distance for infinite timestamp/date - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Date
Msg-id 968df036-44a5-a71b-5d9e-136701fcb2ba@enterprisedb.com
Whole thread Raw
In response to Re: BRIN minmax multi - incorrect distance for infinite timestamp/date  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
List pgsql-hackers
On 10/17/23 22:25, Tomas Vondra wrote:
> Hi,
> 
> Here's a couple cleaned-up patches fixing the various discussed here.
> I've tried to always add a regression test demonstrating the issue
> first, and then fix it in the next patch.
> 
> In particular, this deals with these issues:
> 
> 1) overflows in distance calculation for large timestamp values (0002)
> 
> 2) incorrect subtraction in distance for date values (0003)
> 
> 3) incorrect distance for infinite date/timestamp values (0005)
> 
> 4) failing distance for extreme interval values (0007)
> 
> All the problems except "2" have been discussed earlier, but this seems
> a bit more serious than the other issues, as it's easier to hit. It
> subtracts the values in the opposite order (smaller - larger), so the
> distances are negated. Which means we actually merge the values from the
> most distant ones, and thus are "guaranteed" to build very a very
> inefficient summary. People with multi-minmax indexes on "date" columns
> probably will need to reindex.
> 

BTW when adding the tests with extreme values, I noticed this:

  test=# select '5874897-01-01'::date;
       date
  ---------------
   5874897-01-01
  (1 row)

  test=# select '5874897-01-01'::date + '1 second'::interval;
  ERROR:  date out of range for timestamp

IIUC this happens because the first thing date_pl_interval does is
date2timestamp, ignoring the fact that the ranges of those data types
are different - dates allow values up to '5874897 AD' while timestamps
only allows values up to '294276 AD'.

This seems to be a long-standing behavior, added by a9e08392dd6f in
2004. Not sure how serious it is, I just noticed when I tried to do
arithmetics on the extreme values in tests.


regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix one hint message in 002_pg_upgrade.pl
Next
From: Jelte Fennema
Date:
Subject: Re: run pgindent on a regular basis / scripted manner