Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: client_connection_check_interval default value
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
Date: Mon, 16 Mar 2026 09:36:36 +0800
Cc: =?utf-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>,
 pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC03170F-ABB9-48A8-AE09-1F93BEB5DBE6@gmail.com>
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>
 <017AD77A-21B6-4B0A-8847-207914D53CE0@gmail.com>
 <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DC03170F-ABB9-48A8-AE09-1F93BEB5DBE6%40gmail.com>
Precedence: bulk


> On Mar 13, 2026, at 20:36, Fujii Masao <masao.fujii@gmail.com> wrote:
>=20
> On Tue, Mar 10, 2026 at 10:42=E2=80=AFAM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>>=20
>>=20
>>> On Mar 9, 2026, at 22:12, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>=20
>>> On Mon, Mar 9, 2026 at 6:03=E2=80=AFPM H=C3=BCseyin Demir =
<huseyin.d3r@gmail.com> wrote:
>>>>=20
>>>> Hi Fujii,
>>>>=20
>>>> Thanks for the patch. The rate-limiting approach makes sense to me. =
A couple of thoughts:
>>>>=20
>>>> 1) I think Chao Li's suggestion of using max(10s, deadlock_timeout) =
as the rate limit interval is worth adopting. If someone has set =
deadlock_timeout to, say, 30s or 60s, they've already signaled they =
don't need frequent lock-wait feedback. Logging every 10s after a 60s =
deadlock_timeout feels inconsistent with that intent.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Thought?
>>=20
>> Yeah, IMHO, preserving the existing behavior is preferable. =
Logically, client_connection_check_interval and log_lock_waitsbelong to =
two different departments. Even though they cross paths at the =
implementation level today, having the behavior of log_lock_waits change =
just because client_connection_check_interval is adjusted seems =
surprising.
>=20
> So, attached is a patch that ensures the "still waiting on lock" =
message is
> reported at most once during a lock wait, even if the wait is =
interrupted.
>=20
> Regards,
>=20
> --=20
> Fujii Masao
> <v2-0001-Ensure-still-waiting-on-lock-message-is-logged-on.patch>

V2 overall looks good to me.

A small comment is about the variable name logged_lock_waits that sounds =
like =E2=80=9Ccount of waits=E2=80=9D, I would suggest =
=E2=80=9Clock_wait_logged=E2=80=9D. But I see that the name follows the =
naming convention of the existing variable logged_recovery_conflict, so =
maybe just rename to logged_lock_wait (remove the =E2=80=9Cs=E2=80=9D).

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/