Date: Thu, 5 Feb 2026 17:02:05 -0800
From: Jeremy Schneider <schneider@ardentperf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.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>
Subject: Re: client_connection_check_interval default value
Message-ID: <20260205170205.723c6cc2@ardentperf.com>
In-Reply-To: <1667818.1770336112@sss.pgh.pa.us>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20260205170205.723c6cc2%40ardentperf.com>
Precedence: bulk

On Thu, 05 Feb 2026 19:01:52 -0500
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.  I think it's very likely that there
> are users depending on that behavior.  Jeremy is describing an
> application that evidently was built on the assumption that
> disconnecting early would abort a wait, but that assumption was not
> based on any testing.  I think it's good that we now have an option
> to make such an assumption hold, but that does not translate to
> "we should force that behavior on everybody".  Whether or not the
> overhead is insignificant, there's a good chance that the change
> would make more people unhappy than happy.

This application was trying to kill the connection, the postgres client
attempted to send a cancel message but the cancel message was lost and
the client naturally falls back to just hard killing the network
connection.

I totally understand the cancel messages should not have gotten lost.

But I'm surprised that we'd assume most users who kill -9 their hung
client want their 10 hour query to keep running forever? Yes we always
try to gracefully stop things first and let cancel messages get
through, but I'd think if server received a FIN over the network then we
could interpret that similar to a cancel message. This would be a
change in a new major version; we wouldn't backpatch a GUC default.

I see the concern around the behavior change, but I don't feel like
this difference between CTRL-C and kill-9 should be sancrosact, if
having them behave similarly seems generally reasonable. Postgres has
made more significant changes than this before in major versions.

-Jeremy