Re: client_connection_check_interval default value
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Hüseyin Demir <huseyin.d3r@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-03-09T14:12:29Z
Lists: 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 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? Regards, -- Fujii Masao
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