> 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.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
