On Thu, 2026-02-05 at 19:01 -0500, Tom Lane wrote: > Fujii Masao <[email protected]> writes: > > On Fri, Feb 6, 2026 at 8:05 AM Jeremy Schneider > > <[email protected]> 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
