Hi, 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... > It's also worth pointing out that if you don't trust the kernel clock, > simply clamping to the last returned value isn't likely to be terribly > satisfactory. What if $idiotsysadmin steps the clock back an hour? > We've had actual problems of that sort, for example with the stats > collector going AWOL for awhile because it thought it'd already written a > sufficiently new stats file. There's now an explicit check for clock- > went-backwards in pgstat_recv_inquiry, which will be broken in that sort > of scenario if you cause GetCurrentTimestamp to do clamping internally. I guess you could hack something together with CLOCK_MONOTONIC or such, but brrrr. Greetings, Andres Freund
