Hi, On Thu, Mar 06, 2025 at 02:10:47PM -0500, Andres Freund wrote: > On 2025-01-20 15:01:38 +0000, Bertrand Drouvot wrote: > > /* If start_time is in the future or now, no time has elapsed */ > > if (start_time >= stop_time) > > return 0; > > " > > > > I think that it can happen due to time changes. > > > So with TimestampTz, we would: > > > > 1. return 0 if we moved the time backward > > 2. provide an inflated duration including the time jump (if the time move > > forward). > > > > But with instr_time (and on systems that support CLOCK_MONOTONIC) then > > pg_clock_gettime_ns() should not be affected by system time change IIUC. > > It still does jump around a bit on some systems, even if it shouldn't. It's > not at all rare to see time distontinuities when getting scheduled on another > socket than before
Interesting, yeah I can imagine that could happen. > or when a VM got migrated. It shouldn't happen, but does. Agree, those are convincing examples. > I think it'd be better to use absolute times and store them as such in > ConnectionTimes or whatever. It was still not clear to me why using TimestampTz would be better, until I read: > That way we have information about when a > connection was established for some future SQL functions and for debugging > problems. > Thanks! Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
