Re: [HACKERS] Replication vs. float timestamps is a disaster - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Replication vs. float timestamps is a disaster
Date
Msg-id 3192.1504738508@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Replication vs. float timestamps is a disaster  (Omar Kilani <omar.kilani@gmail.com>)
List pgsql-hackers
Omar Kilani <omar.kilani@gmail.com> writes:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?

Um, not really.  You may be stuck on 9.6 until you can spare the effort
to convert.  The physical representations of timestamps are totally
different in the two cases.

> I did attempt a pg_dumpall | pg_restore at one point but for whatever
> reason we had data in tables that integer datetimes fails on (I forget
> the exact crash, but the datetime values were either too small or too
> large to fit into the integer datetimes field -- I can retry this if
> it would be helpful).

I'm pretty sure the minimum values are the same in both cases, to wit
Julian day zero.  As for the max, according to the old code comments
* The upper limit for dates is 5874897-12-31, which is a bit less than what* the Julian-date code can allow.  We use
thatsame limit for timestamps when* using floating-point timestamps ... For integer timestamps, the upper* limit is
294276-12-31.

I would hope that any timestamps you've got beyond 294276AD are erroneous
data that you need to clean up anyway.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Red-Black tree traversal tests
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump