Re: regression failure - horology - Mailing list pgsql-hackers

From jdc@smof.fiawol.org (John Cochran)
Subject Re: regression failure - horology
Date
Msg-id b3cdpo$2r88$1@smof.fiawol.org
Whole thread Raw
In response to Re: regression failure - horology  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
In article <12354.1045901353@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Joe Conway <mail@joeconway.com> writes:
>> Tom Lane wrote:
>>> Hm, I just had regression tests pass earlier this evening on RHL 8.0
>>> (also HPUX 10.20).  Are you using default config, or
>>> --enable-integer-datetimes?
>
>> I'm using --enable-integer-datetimes on both.
>

It looks like the regression checks need to use two different formats
depending on if integer-timestamps is being used.

For the normal floating point timestamps, the regression checks are correct
since all timestamps between 4713BC to 5874897AD.

However using a 64 bit integer to represented as number of microseconds since
Jan 1, 2000 gives the following reduced range of 4713BC to about 294277AD.
In order to represent to full range of timestamps for julian day counts from 0
to 2147483647 to the nearest microsecond, you require:  31 bits for the day  17 bits for the second  20 bits for the
microsecond
for a total of 68 bits needed to represent the full range of timestamps to
the nearest microsecond.

Suggested fix would be one or more of the following:  1. Reduce the range tested within the regression checks to what
is    capable for integer timestamps.  2. Use two different regression checks depending on if integer timestamps
arein use.  3. Document the different ranges for timestamps depending on if integer     timestamps are in use.
 


pgsql-hackers by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: Simplifying timezone support
Next
From: Radha Manohar
Date:
Subject: Figures in Developer's guide