Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Subject: Re: client_connection_check_interval default value
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <CAHGQGwGw4LhNwOGQT3nbw3uWy8gL94_MB4T39Wfr4_Vgopuovg@mail.gmail.com>
Date: Tue, 24 Feb 2026 14:01:36 +0800
Cc: 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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA1CDB0F-9DB3-47B6-9FEE-6B35370AF110@gmail.com>
References: <20260204213032.15bab46b@ardentperf.com>
 <CAOYmi+nS69LiUExZF=gGZ+NJU-SCNQ59qJTiWtJw96cDdi9iSg@mail.gmail.com>
 <20260205150452.00006167@ardentperf.com>
 <CAHGQGwHZUmg+r4kMcPYt_Z-txxVX+CJJhfra+qemxKXvAxYbpw@mail.gmail.com>
 <1667818.1770336112@sss.pgh.pa.us>
 <CAHGQGwGw4LhNwOGQT3nbw3uWy8gL94_MB4T39Wfr4_Vgopuovg@mail.gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/DA1CDB0F-9DB3-47B6-9FEE-6B35370AF110%40gmail.com>
Precedence: bulk


> On Feb 18, 2026, at 13:30, Fujii Masao <masao.fujii@gmail.com> wrote:
>=20
> On Fri, Feb 6, 2026 at 9:01=E2=80=AFAM 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.
>>=20
>> 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.
>=20
> Attached is a patch that rate-limits the "still waiting on lock" =
message
> to at most once every 10s.
>=20
> 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.
>=20
> Thoughts?
>=20
> --=20
> Fujii Masao
> <v1-0001-Rate-limit-repeated-still-waiting-on-lock-log-mes.patch>

I feel 10 seconds is good.

The other thinking is that, the message will only be printed after the =
first deadlock check is fired. So, if someone sets deadlock_timeout to a =
large value, say 30 or 60 seconds, then any waiting log would already be =
very delayed. In that case, the user might not want to log more often =
than deadlock checks anyway. =46rom this perspective, the rate limit =
timeout could be max(10s, deadlock_timeout). Anyway, this is not a =
strong opinion.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/