Re: Replication vs. float timestamps is a disaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Omar Kilani <omar(dot)kilani(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication vs. float timestamps is a disaster
Date: 2017-09-06 22:55:08
Message-ID: 3192.1504738508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Omar Kilani <omar(dot)kilani(at)gmail(dot)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 that same 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-09-06 23:42:07 Re: Patch: Add --no-comments to skip COMMENTs with pg_dump
Previous Message Tom Lane 2017-09-06 22:38:11 Re: Red-Black tree traversal tests