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@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 +