Both the streaming replication and logical replication areas of the code are, approximately, utterly broken when !HAVE_INT64_TIMESTAMPS. (The fact that "make check-world" passes anyway is an indictment of the quality of the regression tests.)
I started poking around in this area after Thomas Munro reported that pg_recvlogical.c no longer even compiles with --disable-integer-datetimes, but the problems go much deeper than that. replication/logical/worker.c's send_feedback() is sending a backend timestamp directly as sendTime. This is wrong per the protocol spec, which says the field is an integer timestamp. I'm not sure if it's OK to just replace - pq_sendint64(reply_message, now); /* sendTime */ + pq_sendint64(reply_message, GetCurrentIntegerTimestamp()); /* sendTime */ ... is it important for the sent timestamp to exactly match the timestamp that was used earlier in the function for deciding whether to send or not? Should we instead try to convert the earlier logic to use integer timestamps? As for logical replication, logicalrep_write_begin and logicalrep_write_commit are likewise sending TimestampTz values using pq_sendint64, and this is much harder to patch locally since the values were taken from WAL records that contain TimestampTz. Although the sent values are nonsensical according to the protocol spec, logicalrep_read_begin and logicalrep_read_commit read them with pq_getmsgint64 and assign the results back to TimestampTz, which means that things sort of appear to work as long as you don't mind losing all sub-second precision in the timestamps. (But a decoder that was written to spec would think the values are garbage.) I'm inclined to think that at least for logical replication, we're going to have to give up the protocol spec wording that says that timestamps are integers, and instead admit that they are dependent on disable-integer-datetimes. Maybe we should do the same in the streaming replication protocol, because this area is going to be a very fertile source of bugs for the foreseeable future if we don't. It's not like replication between enable-integer-datetimes and disable-integer-datetimes hosts has any chance of being useful anyway. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers