Re: Log connection establishment timings

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: Log connection establishment timings
Дата
Msg-id CAAKRu_Y0vHiDZgsnPriUeFe22NJz6zx-ukbODYJPHreAE1iONQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Log connection establishment timings  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Ответы Re: Log connection establishment timings
Список 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 по дате отправления: