Andres Freund <and...@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