From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>
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: Mon, 27 Feb 2017 19:53:56 -0500
Message-ID: <20170228005356.GA11339@momjian.us> (raw)
In-Reply-To: <31590.1487599653@sss.pgh.pa.us>
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>
<20170220110456.2jupmfhxlizykmmc@alap3.anarazel.de>
<31590.1487599653@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Mon, Feb 20, 2017 at 09:07:33AM -0500, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps. I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build since we switched the default in 8.4. Maybe there is somebody
> who's faithfully built a float-timestamp custom build every year so they
> can pg_upgrade in place from their 8.3 installation, but there have got
> to be darn few such people.
>
> As for "proper deprecation period", the documentation has called the
> option deprecated since 8.4:
>
> -disable-integer-datetimes
> Disable support for 64-bit integer storage for timestamps and
> intervals, and store datetime values as floating-point numbers
> instead. Floating-point datetime storage was the default in
> PostgreSQL releases prior to 8.4, but it is now deprecated,
> because it does not support microsecond precision for the full
> range of timestamp values.
>
> I think the strongest reason why we didn't move to kill it sooner was
> that we were not then assuming that every platform had 64-bit ints;
> but we've required that since 9.0.
I agree with removing support for float timestamps in PG 10. It would
be tempting to think we can reuse the bits we stopped using in 9.0 for
VACUUM FULL, e.g.:
#define HEAP_MOVED_OFF 0x4000 /* moved to another place by pre-9.0
* VACUUM FULL; kept for binary
* upgrade support */
#define HEAP_MOVED_IN 0x8000 /* moved from another place by pre-9.0
* VACUUM FULL; kept for binary
* upgrade support */
However, if users built Postgres 8.4 with integer timestamps, they could
still be in the data files. Does anyone see a fault in my logic, I
hope?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
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: bruce@momjian.us, tgl@sss.pgh.pa.us, andres@anarazel.de, petr.jelinek@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Replication vs. float timestamps is a disaster
In-Reply-To: <20170228005356.GA11339@momjian.us>
* 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