Re: client_connection_check_interval default value - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: client_connection_check_interval default value
Date
Msg-id CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com
Whole thread
In response to Re: client_connection_check_interval default value  (Hüseyin Demir <huseyin.d3r@gmail.com>)
Responses Re: client_connection_check_interval default value
Re: client_connection_check_interval default value
List pgsql-hackers
On Mon, Mar 9, 2026 at 6:03 PM Hüseyin Demir <huseyin.d3r@gmail.com> 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
someonehas 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?

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
Next
From: Aleksander Alekseev
Date:
Subject: Refactoring proposal: initialize structures in a consistent way