On Fri, Mar 7, 2025 at 10:09 AM Bertrand Drouvot
<bertranddrouvot...@gmail.com> wrote:
>
> Given that conn_timing.ready_for_use is only used here:
>
> + if (!reported_first_ready_for_query &&
> + (log_connections &
> LOG_CONNECTION_READY_FOR_USE) &&
> + IsConnectionBackend(MyBackendType))
> + {
> + uint64 total_duration,
> + fork_duration,
> + auth_duration;
> +
> + conn_timing.ready_for_use =
> GetCurrentTimestamp();
> +
> + total_duration =
> +
> TimestampDifferenceMicroseconds(conn_timing.socket_create,
> +
> conn_timing.ready_for_use);
>
> I wonder if ready_for_use needs to be part of ConnectionTiming after all.
> I mean we could just:
>
> "
> total_duration = TimestampDifferenceMicroseconds(conn_timing.socket_create,
> GetCurrentTimestamp())
> "
>
> That said, having ready_for_use part of ConnectionTiming could be
> useful if we decide to create a SQL API on top of this struct though. So,
> that's probably fine and better as it is.
That's what I was thinking. It felt like good symmetry to have it there.
> And if we keep it part of ConnectionTiming, then:
>
> === 02
>
> + if (!reported_first_ready_for_query &&
> + (log_connections &
> LOG_CONNECTION_READY_FOR_USE) &&
> + IsConnectionBackend(MyBackendType))
>
> What about getting rid of reported_first_ready_for_query and check if
> conn_timing.ready_for_use is zero instead?
Unfortunately, I think a TimestampTz value of 0 corresponds to
1970-01-01 00:00:00 UTC, which is a valid timestamp.
- Melanie
