Re: Replication vs. float timestamps is a disaster

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(at)momjian(dot)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 +