Re: Log connection establishment timings
От | Melanie Plageman |
---|---|
Тема | Re: Log connection establishment timings |
Дата | |
Msg-id | CAAKRu_YrNsA7-v5L9d318XZu+tPqcxp+ctCGy2EGYrSt69ON=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Log connection establishment timings (Guillaume Lelarge <guillaume@lelarge.info>) |
Ответы |
Re: Log connection establishment timings
|
Список | pgsql-hackers |
Thanks for taking a look! On Mon, Jan 20, 2025 at 10:01 AM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > > The patch needed a rebase due to 34486b6092e. I did it in v2 attached (it's > a minor rebase due to the AmRegularBackendProcess() introduction in miscadmin.h). > > v2 could rely on AmRegularBackendProcess() instead of AmClientBackendProcess() > but I kept it with AmClientBackendProcess() to reduce "my" changes as compared to > v1. Thanks for doing this! I have implemented your suggestion in attached v3. > Regarding the TimestampTz vs instr_time choice, we have things like: < -- snip -- > > 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. > > 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. Great point. This all makes sense. I've switched to using instr_time in v3. - Melanie
Вложения
В списке pgsql-hackers по дате отправления: