Re: Log connection establishment timings - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Log connection establishment timings
Date
Msg-id CAAKRu_Y0vHiDZgsnPriUeFe22NJz6zx-ukbODYJPHreAE1iONQ@mail.gmail.com
Whole thread Raw
In response to Re: Log connection establishment timings  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Fri, Feb 28, 2025 at 12:16 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Yup but my idea was to put all those line:
>
> "
>     if (Log_connections &&
>         (child_type == B_BACKEND || child_type == B_WAL_SENDER))
>     {
>         instr_time  fork_time = ((BackendStartupData *) startup_data)->fork_time;
>
>         conn_timing.fork_duration = INSTR_TIME_GET_DURATION_SINCE(fork_time);
>     }
> "
>
> into a dedicated helper function.

I ended up finding a bug that means that that exact code isn't
duplicated twice now. For EXEC_BACKEND, I have to wait to calculate
the duration until after reading the GUC values but I need to get the
fork end time before that.

I tried coming up with an inline helper to replace this and most
things I tried felt awkward. It has to have backend type and start
time as parameters. And all of these places we have to be super
careful that the GUCs have already been read before using
log_connections, so it seems a bit unsafe to check log_connections
(the global variable) in a function. Someone could call the function
in a different place and maybe not know that log_connections won't be
set there.

Also, I also wasn't sure if it would be weird to call a function like
"LogConnectionTiming()" which in many cases doesn't log the connection
timing (because it is a different backend type).

But maybe I'm not thinking about it correctly. What were you imagining?

- Melanie



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: making EXPLAIN extensible
Next
From: Alvaro Herrera
Date:
Subject: Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints