Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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: struct-integer-timestamp.patch
Description: text/x-diff (46.6 KB)

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group