Re: client_connection_check_interval default value
Hüseyin Demir <huseyin.d3r@gmail.com>
From: Hüseyin Demir <huseyin.d3r@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Cc: Fujii Masao <masao.fujii@gmail.com>
Date: 2026-03-09T09:02:26Z
Lists: pgsql-hackers
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. 2) The hardcoded 10s constant — could we define it as a named constant in a header file? That way it's easier to find and reason about if it ever needs to change. 3) Would it make sense to add a regression test for this? Something that verifies the rate limiting actually suppresses the repeated messages at the expected interval. 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