Brent Kerby <blkerby@gmail.com> writes:
> What I propose is that we could add a boolean configuration option, say
> 'ensure_monotonic_timestamps', that enables the following behavior: when
> GetCurrentTimestamp is called (
> https://doxygen.postgresql.org/backend_2utils_2adt_2timestamp_8c.html#a9822cdf3fd41b15851c0c18ddc80143c),
> before it returns it checks if `result` is less than what was returned last
> time (if any) that GetCurrentTimestamp was called, and if so it returns the
> result from the previous call (after logging a warning), otherwise it
> proceeds as normal. In its simplest form, this could be accomplished by
> adding a global variable lastGetCurrentTimestamp that stores the result of
> the previous call.
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.
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.
On the whole, the alternative of solving the problem at the kernel level
seems preferable to me.
regards, tom lane
