Re: Keeping pg_recvlogical's "feTimestamp" separate from TimestampTz

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: Re: Keeping pg_recvlogical's "feTimestamp" separate from TimestampTz
Date: 2017-02-18 22:18:44
Message-ID: 27694.1487456324@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I propose that what we need to do is get rid of the dangerous and
> none-too-readable-anyway use of "int64" to declare replication-protocol
> timestamps, and instead declare them as, say,

> typedef struct RPTimestamp
> {
> int64 rptimestamp;
> } RPTimestamp;

I experimented with this a bit, as in the attached draft patch, and
concluded that use of a struct is probably a bridge too far. It makes the
patch pretty invasive notationally, and yet it still fails to catch places
where nobody had bothered to even think about float timestamps anywhere
nearby; which there are several of, as per my report
https://www.postgresql.org/message-id/26788.1487455319@sss.pgh.pa.us

We might be able to salvage the parts of this that simply redeclare
appropriate variables as "IntegerTimestamp" rather than "int64", with
the type declaration just being "typedef int64 IntegerTimestamp".
If we go forward with keeping protocol fields as integer timestamps
then I'd want to do that, just so we have some notation in the code
as to what the values are meant to be. But right at the moment I'm
thinking we'd be better off to change them all to TimestampTz instead,
and adjust the arithmetic on them appropriately.

regards, tom lane

Attachment Content-Type Size
struct-integer-timestamp.patch text/x-diff 46.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-02-18 22:26:34 Re: pg_get_object_address() doesn't support composites
Previous Message Tom Lane 2017-02-18 22:01:59 Replication vs. float timestamps is a disaster