Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Date
Msg-id 25638.1458157187@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
List pgsql-hackers
I had almost gotten to the point of being willing to commit this patch
when I noticed that it fails to fix the originally-complained-of-problem:

regression=# set time zone 'GMT+1';
SET
regression=# select '4714-11-24 00:00:00+00 BC'::timestamptz;       timestamptz        
---------------------------4714-11-23 23:00:00-01 BC
(1 row)

regression=# select '4714-11-23 23:00:00-01 BC'::timestamptz;
ERROR:  timestamp out of range: "4714-11-23 23:00:00-01 BC"
LINE 1: select '4714-11-23 23:00:00-01 BC'::timestamptz;              ^

The problem here is that the timestamp satisfies IS_VALID_TIMESTAMP just
fine, but its printed form contains a date that the Julian-day routines
can't handle.

AFAICS the only way that we can avoid a dump/reload hazard is to tighten
up the allowed range of timestamps by at least one day, so that any
timestamp that passes IS_VALID_TIMESTAMP() is guaranteed to print, in
any timezone, with a contained date that the Julian-day routines can
handle.  I'd be inclined to set the lower limit of timestamps as
'4713-01-01 00:00 GMT BC' just to keep things simple.  (The upper limit
can stay where it is.)

While dates don't have this timezone rotation problem, the documentation
says that they have the same lower-bound limit as timestamps, and there
are places in the code that assume that too.  Is it okay to move their
lower bound as well?
        regards, tom lane



pgsql-hackers by date:

Previous
From: otheus uibk
Date:
Subject: Re: async replication code
Next
From: Robert Haas
Date:
Subject: Re: Performance degradation in commit ac1d794