Re: [HACKERS] Replication vs. float timestamps is a disaster

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Replication vs. float timestamps is a disaster
Дата
Msg-id 3192.1504738508@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Replication vs. float timestamps is a disaster  (Omar Kilani <omar.kilani@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Red-Black tree traversal tests
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump