On Thu, 2026-02-05 at 19:01 -0500, Tom Lane wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
> > On Fri, Feb 6, 2026 at 8:05 AM Jeremy Schneider
> > <schneider@ardentperf.com> wrote:
> > > I did see a real system outage that could have been prevented by an
> > > appropriate default value here, since I didn't yet know to change it.
>
> > I'm not sure that client_connection_check_interval needs to be enabled
> > by default.
>
> I think enabling it by default is a nonstarter, because it changes
> behavior in a significant way. Specifically, it's always been the
> case that if the client disconnects during a non-SELECT query (or
> anything that doesn't produce output), the backend would complete that
> query before ending the session. I think it's very likely that there
> are users depending on that behavior.
*Perhaps* there are some users who depend on the current behavior, but
my experience is that the vast majority of users don't want that statements
started by a connection that went dead should keep running.
I mean, it would be a change in behavior, but that is normal during a
major upgrade, and users who actively want the current behavior can
disable client_connection_check_interval.
I think that enabling client_connection_check_interval would be a net win,
as far as the core functionality is concerned.
Fujii Masao's concern that log_lock_waits would issue a message every
client_connection_check_interval is much more serious in my opinion, now
that log_lock_waits is enabled by default (at - erm - my insistence).
Why does the deadlock detector kick in every client_connection_check_interval?
Yours,
Laurenz Albe
