MIME-Version: 1.0
References: <20260204213032.15bab46b@ardentperf.com>
 <CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA@mail.gmail.com>
 <177304694613.1094603.10800724073727441272.pgcf@coridan.postgresql.org>
 <CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com>
 <017AD77A-21B6-4B0A-8847-207914D53CE0@gmail.com>
 <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
In-Reply-To: 
 <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
From: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>
Date: Mon, 16 Mar 2026 08:04:53 +0100
Message-ID: 
 <CAB5wL7YB1my9W5k5i=SY+=sTjeozyJ0YkvGXrVfeDNzuRkoTPg@mail.gmail.com>
Subject: Re: client_connection_check_interval default value
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAB5wL7YB1my9W5k5i%3DSY%2B%3DsTjeozyJ0YkvGXrVfeDNzuRkoTPg%40mail.gmail.com>
Precedence: bulk

Hi,

Fujii Masao <masao.fujii@gmail.com>, 13 Mar 2026 Cum, 13:36 tarihinde
=C5=9Funu yazd=C4=B1:
>
> On Tue, Mar 10, 2026 at 10:42=E2=80=AFAM Chao Li <li.evan.chao@gmail.com>=
 wrote:
> >
> >
> >
> > > On Mar 9, 2026, at 22:12, Fujii Masao <masao.fujii@gmail.com> wrote:
> > >
> > > On Mon, Mar 9, 2026 at 6:03=E2=80=AFPM H=C3=BCseyin Demir <huseyin.d3=
r@gmail.com> wrote:
> > >>
> > >> 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_t=
imeout to, say, 30s or 60s, they've already signaled they don't need freque=
nt lock-wait feedback. Logging every 10s after a 60s deadlock_timeout feels=
 inconsistent with that intent.
> > >
> > > Or perhaps they expect the log message to be emitted only once,
> > > just after deadlock_timeout, similar to the current behavior when
> > > client_connection_check_interval is not set, I guess.
> > >
> > > I'm now starting thinking it might be better to preserve the existing
> > > behavior (emitting the message once per wait) regardless of whether
> > > client_connection_check_interval is set, and implement that first.
> > >
> > > If there is a need to emit the message periodically, we could add tha=
t
> > > as a separate feature later so that it works independently of
> > > the client_connection_check_interval setting.
> > >
> > > Thought?
> >
> > Yeah, IMHO, preserving the existing behavior is preferable. Logically, =
client_connection_check_interval and log_lock_waitsbelong to two different =
departments. Even though they cross paths at the implementation level today=
, having the behavior of log_lock_waits change just because client_connecti=
on_check_interval is adjusted seems surprising.
>
> So, attached is a patch that ensures the "still waiting on lock" message =
is
> reported at most once during a lock wait, even if the wait is interrupted=
.
>

The new v2 patch looks good to me.

One open question from my side is should we include a test for this
behaviour ? Because we mentioned adding a different GUC in the future
to manage this rate-limiting approach. It can be useful in the future
once we consider/re-visit this approach. If the tests and other future
ideas can be developed later together we can consider adding tests
later.

Thanks for the patch again!

Regards.