From: David Fetter <david@fetter.org>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Replication vs. float timestamps is a disaster
Date: Wed, 22 Feb 2017 09:22:28 -0800
Message-ID: <20170222172228.GA22565@fetter.org> (raw)
In-Reply-To: <3bd3c551-8b23-45c8-27a2-97b5a922b130@2ndquadrant.com>
References: <26788.1487455319@sss.pgh.pa.us>
<CA+TgmoafyUzmg8T-rKEgmkX7F1iQLSrKBmqKa26EattXpMS-ng@mail.gmail.com>
<1691.1487519369@sss.pgh.pa.us>
<20170220070311.gscn7ppqbwlgdpjq@alap3.anarazel.de>
<3bd3c551-8b23-45c8-27a2-97b5a922b130@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: david@fetter.org, petr.jelinek@2ndquadrant.com, andres@anarazel.de, tgl@sss.pgh.pa.us, robertmhaas@gmail.com
Subject: Re: Replication vs. float timestamps is a disaster
In-Reply-To: <20170222172228.GA22565@fetter.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox