Re: client_connection_check_interval default value

Fujii Masao <masao.fujii@gmail.com>

From: Fujii Masao <masao.fujii@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-18T05:30:22Z
Lists: pgsql-hackers

Attachments

On Fri, Feb 6, 2026 at 9:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > The issue is that backends blocked in ProcSleep() are woken up every
> > client_connection_check_interval and may emit a "still waiting" message
> > each time if log_lock_waits is enabled. To mitigate this, just one idea is
> > to add a flag to track whether the "still waiting" message has already been
> > emitted during a call to ProcSleep(), and suppress further messages
> > once it has been logged.
>
> Independently of what's the default, it seems like it'd be valuable to
> make that interaction better.  I think it is reasonable to keep on
> emitting "still waiting" every so often, but we could probably
> rate-limit that to a lot less than every 2 seconds.

Attached is a patch that rate-limits the "still waiting on lock" message
to at most once every 10s.

I chose 10s instead of the suggested 2s, since 2s felt too short. But we can
discuss the appropriate interval and adjust it if needed. The value is
currently hard-coded, as making it configurable does not seem necessary.

Thoughts?

-- 
Fujii Masao

Commits

  1. Add TAP tests for log_lock_waits

  2. Add tests for lock statistics, take two

  3. Ensure "still waiting on lock" message is logged only once per wait.