MIME-Version: 1.0
References: <20260204213032.15bab46b@ardentperf.com>
 <CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA@mail.gmail.com>
 <177304694613.1094603.10800724073727441272.pgcf@coridan.postgresql.org>
 <CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com>
From: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>
Date: Mon, 9 Mar 2026 19:18:05 +0100
Message-ID: 
 <CAB5wL7ZaQ3bTT+Db2R0s_RyQhk6ikFRn3TqjCodrL7wznATaqg@mail.gmail.com>
Subject: Re: client_connection_check_interval default value
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000036490e064c9b6d1a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB5wL7ZaQ3bTT%2BDb2R0s_RyQhk6ikFRn3TqjCodrL7wznATaqg%40mail.gmail.com>
Precedence: bulk

--00000000000036490e064c9b6d1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Fujii Masao <masao.fujii@gmail.com>, 9 Mar 2026 Pzt, 15:12 tarihinde =C5=9F=
unu
yazd=C4=B1:

> Or perhaps they expect the log message to be emitted only once,
> just after deadlock_timeout, similar to the current behavior when
> client_connection_check_interval is not set, I guess.
>
> I'm now starting thinking it might be better to preserve the existing
> behavior (emitting the message once per wait) regardless of whether
> client_connection_check_interval is set, and implement that first.
>
> If there is a need to emit the message periodically, we could add that
> as a separate feature later so that it works independently of
> the client_connection_check_interval setting.
>
>
+1 to this idea. It would be a better approach in the future if we need to
change the behaviour of emitting logs about these topics.

I do see the trade-off. Put simply with only one message, we can lose
visibility into long lock waits. But I think that's a separate concern. If
there's a real need for periodic "still waiting" messages in the future, we
could introduce a dedicated GUC (something like log_lock_waits_interval) or
even a simple constant to control that independently of
client_connection_check_interval. That way deadlock detection, connection
checking, and lock-wait logging each have their own rules and don't
interfere with each other.

Regards.

--00000000000036490e064c9b6d1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div>Hi,=C2=A0<br><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Fu=
jii Masao &lt;<a href=3D"mailto:masao.fujii@gmail.com">masao.fujii@gmail.co=
m</a>&gt;, 9 Mar 2026 Pzt, 15:12 tarihinde =C5=9Funu yazd=C4=B1:</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
Or perhaps they expect the log message to be emitted only once,<br>
just after deadlock_timeout, similar to the current behavior when<br>
client_connection_check_interval is not set, I guess.<br>
<br>
I&#39;m now starting thinking it might be better to preserve the existing<b=
r>
behavior (emitting the message once per wait) regardless of whether<br>
client_connection_check_interval is set, and implement that first.<br>
<br>
If there is a need to emit the message periodically, we could add that<br>
as a separate feature later so that it works independently of<br>
the client_connection_check_interval setting.<br><br></blockquote><div><br>=
</div><div>+1 to this idea. It would be a better approach in the future if =
we need to change the behaviour=C2=A0of emitting logs about these topics.=
=C2=A0<br></div><div><br></div><div>I do see the trade-off. Put simply with=
 only one message, we can lose visibility into long lock waits. But I think=
 that&#39;s a separate concern. If there&#39;s a real need for periodic &qu=
ot;still waiting&quot; messages in the future, we could introduce a dedicat=
ed GUC (something like log_lock_waits_interval) or even a simple constant t=
o control that independently of client_connection_check_interval. That way =
deadlock detection, connection checking, and lock-wait logging each have th=
eir own rules and don&#39;t interfere with each other.</div><div><br></div>=
<div>Regards.</div><div>=C2=A0</div></div></div>

--00000000000036490e064c9b6d1a--