public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chao Li <[email protected]>
To: Fujii Masao <[email protected]>
Cc: Hüseyin Demir <[email protected]>
Cc: [email protected]
Subject: Re: client_connection_check_interval default value
Date: Mon, 16 Mar 2026 09:36:36 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
References: <[email protected]>
<CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA@mail.gmail.com>
<177304694613.1094603.10800724073727441272.pgcf@coridan.postgresql.org>
<CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com>
<[email protected]>
<CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
> On Mar 13, 2026, at 20:36, Fujii Masao <[email protected]> wrote:
>
> On Tue, Mar 10, 2026 at 10:42 AM Chao Li <[email protected]> wrote:
>>
>>
>>
>>> On Mar 9, 2026, at 22:12, Fujii Masao <[email protected]> wrote:
>>>
>>> On Mon, Mar 9, 2026 at 6:03 PM Hüseyin Demir <[email protected]> wrote:
>>>>
>>>> Hi Fujii,
>>>>
>>>> Thanks for the patch. The rate-limiting approach makes sense to me. A couple of thoughts:
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>> Thought?
>>
>> 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.
>
> 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.
>
> Regards,
>
> --
> 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 “count of waits”, I would suggest “lock_wait_logged”. 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 “s”).
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: client_connection_check_interval default value
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox