Horton

Re: client_connection_check_interval default value

Jacob Champion <jacob.champion@enterprisedb.com>

View thread View on postgr.es
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>, Jeremy Schneider <schneider@ardentperf.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>
Date: 2026-02-06T00:18:50Z
Lists: pgsql-hackers 
On Thu, Feb 5, 2026 at 4:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Ha, I hadn't even thought about the possibility of fire-and-forget...

> I think it's very likely that there
> are users depending on that behavior.

From a quick search, yeah, probably:

    https://dba.stackexchange.com/questions/247206/will-query-continue-to-run-even-after-network-times-out

--Jacob

Commits

  1. Add TAP tests for log_lock_waits

  2. Add tests for lock statistics, take two

  3. Ensure "still waiting on lock" message is logged only once per wait.