Andres Freund <andres@anarazel.de> writes:
> On 2018-02-20 12:32:22 -0500, Tom Lane wrote:
>> The "global" variable would actually need to be cluster-wide, ie in shared
>> memory, which would imply contention and the need for locks. I think the
>> overhead of this would be mighty high, and the return pretty low.
> I think if we wanted to go for something like this (which I doubt), we'd
> have that global variable as an atomic 64bit variable in shmem, and
> *only* use it for stuff where the ordering actually matters. I.e. not
> for transaction start times etc...
Then you've got problems with figuring out which usages "matter" and which
don't, and being sure you don't ever compare timestamps from the two
different sources. Seems mighty fragile to me, and reminiscent of the
replication problems that forced us to drop support for float timestamps.
In any case I'd not much like a system that mostly reported in system
clock time except transaction commit timestamps are on some other
timescale.
But really, the killer point here is your upthread comment that even if
GetCurrentTimestamp were guaranteed to return monotonic time, that would
not guarantee that commit timestamps match physical commit order, which
was the OP's goal. At least not unless we read the clock while holding
WALWriteLock, which I'm pretty sure everyone will say Ain't Happening.
I think your not-very-explicit suggestion that he should work in
commit LSNs, not timestamps at all, is a far superior answer.
regards, tom lane