MIME-Version: 1.0
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>
 <b821da13765cd5a0c948e60cd5cd38856840d021.camel@cybertec.at> <CANwKhkN7DAY832b6Vefb3guzi2CCyF89HT1_Jei8PUP2rop0MA@mail.gmail.com>
In-Reply-To: <CANwKhkN7DAY832b6Vefb3guzi2CCyF89HT1_Jei8PUP2rop0MA@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Thu, 26 Feb 2026 10:30:40 +0900
Message-ID: <CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA@mail.gmail.com>
Subject: Re: client_connection_check_interval default value
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 18, 2026 at 6:00=E2=80=AFPM 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" messag=
e
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,

--=20
Fujii Masao