Re: client_connection_check_interval default value
Hüseyin Demir <huseyin.d3r@gmail.com>
From: Hüseyin Demir <huseyin.d3r@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-03-09T18:18:05Z
Lists: pgsql-hackers
Hi, Fujii Masao <masao.fujii@gmail.com>, 9 Mar 2026 Pzt, 15:12 tarihinde şunu yazdı: > 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.
Commits
-
Add TAP tests for log_lock_waits
- ca2b5443e2dc 19 (unreleased) landed
-
Add tests for lock statistics, take two
- 557a9f1e3e62 19 (unreleased) cited
-
Ensure "still waiting on lock" message is logged only once per wait.
- fd6ecbfa75ff 19 (unreleased) landed