Re: Replication vs. float timestamps is a disaster
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-02-22T17:22:28Z
Lists: pgsql-hackers
On Mon, Feb 20, 2017 at 11:58:12AM +0100, Petr Jelinek wrote: > On 20/02/17 08:03, Andres Freund wrote: > > On 2017-02-19 10:49:29 -0500, Tom Lane wrote: > >> Robert Haas <robertmhaas@gmail.com> writes: > >>> On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>>> Thoughts? Should we double down on trying to make this work according > >>>> to the "all integer timestamps" protocol specs, or cut our losses and > >>>> change the specs? > >> > >>> I vote for doubling down. It's bad enough that we have so many > >>> internal details that depend on this setting; letting that cascade > >>> into the wire protocol seems like it's just letting the chaos spread > >>> farther and wider. > >> > >> How do you figure that it's not embedded in the wire protocol already? > >> Not only the replicated data for a timestamp column, but also the > >> client-visible binary I/O format, depend on this. I think having some > >> parts of the protocol use a different timestamp format than other parts > >> is simply weird, and as this exercise has shown, it's bug-prone as all > >> get out. > > > > I don't think it's that closely tied together atm. Things like > > pg_basebackup, pg_receivexlog etc should work, without having to match > > timestamp storage. Logical replication, unless your output plugin dumps > > data in binary / "raw" output, also works just fine across the timestamp > > divide. > > > > It doesn't sound that hard to add a SystemToIntTimestamp() function, > > given it only needs to do something if float timestamps are enabled? > > > > It's definitely not hard, we already have > IntegerTimestampToTimestampTz() which does the opposite conversion anyway. > > That being said, I did wonder myself if we should just deprecate float > timestamps as well. +1 for deprecating them. If we need a timestamp(tz) with a wider range, we are getting options we didn't have before for implementing it. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Commits
-
Consistently declare timestamp variables as TimestampTz.
- c29aff959dc6 10.0 landed
-
Remove now-dead code for !HAVE_INT64_TIMESTAMP.
- b9d092c962ea 10.0 landed
-
Remove pg_control's enableIntTimes field.
- d28aafb6dda3 10.0 landed
-
De-support floating-point timestamps.
- b6aa17e0ae36 10.0 landed
-
Make integer_datetimes the default for MSVC even if not mentioned in config.pl.
- fcf053d7829f 8.4.0 cited
-
Enable 64-bit integer datetimes by default, per previous discussion.
- 2169e42bef9d 8.4.0 cited