Re: Log connection establishment timings
От | Andres Freund |
---|---|
Тема | Re: Log connection establishment timings |
Дата | |
Msg-id | x5tc52wvbbzblmp75xdkt62k4tgsvhrdyajpcmqgvi2gpkdvkm@zxrrmcp26zav обсуждение исходный текст |
Ответ на | Re: Log connection establishment timings (Guillaume Lelarge <guillaume@lelarge.info>) |
Ответы |
Re: Log connection establishment timings
Re: Log connection establishment timings |
Список | pgsql-hackers |
Hi, On 2025-01-20 15:01:38 +0000, Bertrand Drouvot wrote: > Regarding the TimestampTz vs instr_time choice, we have things like: > > + TimestampTz fork_time = ((BackendStartupData *) startup_data)->fork_time; > + TimestampTz cur_time = GetCurrentTimestamp(); > + > + conn_timing.fork_duration = TimestampDifferenceMicroseconds(fork_time, > + cur_time); > > but looking at TimestampDifferenceMicroseconds(): > > " > /* 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. It shouldn't during proper operation, the time should be accellerated or slowed down, but not have backwards jumps. > 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 or when a VM got migrated. It shouldn't happen, but does. > Though time changes are "rare", given the fact that those metrics could provide > "inaccurate" measurements during that particular moment (time change) then it > might be worth considering instr_time instead for this particular metric. We calculate the times for log_min_duration_statement etc via GetCurrentTimestamp(), I don't think it's worth worrying about that here. I think it'd be better to use absolute times and store them as such in ConnectionTimes or whatever. That way we have information about when a connection was established for some future SQL functions and for debugging problems. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: