Re: client_connection_check_interval default value
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Ants Aasma <ants.aasma@cybertec.at>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Tom Lane <tgl@sss.pgh.pa.us>, Jeremy Schneider <schneider@ardentperf.com>,
Jacob Champion <jacob.champion@enterprisedb.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Marat Buharov <marat.buharov@gmail.com>,
Greg Sabino Mullane <htamfids@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2026-02-26T01:30:40Z
Lists: pgsql-hackers
On Wed, Feb 18, 2026 at 6:00 PM Ants Aasma <ants.aasma@cybertec.at> wrote: > I think 10 seconds is way too small. Having one long locker blocking a > couple hundred backends is something that happens somewhat regularly. > A 10s interval would result in tens of "still waiting" per second. It > will just make it harder to sift out what is actually going on between > all the waiters squawking "are we there yet?" in a loop. > > I think something above 5 minutes would be more appropriate. For that scenario, wouldn't it be better to emit the "still waiting" message only once per lock wait (i.e., use the same behavior) regardless of the client_connection_check_interval setting, rather than repeating it every several minutes? Also logging it again after a long delay like 5min could be confusing to users. I used 10s in the patch, on the other hand I'm also ok with preserving the existing behavior (emit once per wait) whether client_connection_check_interval is set or not. Even without periodic log messages, ongoing lock waits can still be monitored via pg_locks. 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