Re: Log connection establishment timings

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, andrey(dot)chudnovskiy(at)microsoft(dot)com, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Subject: Re: Log connection establishment timings
Date: 2025-03-07 10:33:33
Message-ID: Z8rLfS8h8eXBJKuf@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-03-07 10:41:10 Re: speedup COPY TO for partitioned table.
Previous Message Jim Jones 2025-03-07 10:27:34 Re: pg_dump, pg_dumpall, pg_restore: Add --no-policies option