public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeremy Schneider <[email protected]>
To: Tom Lane <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Marat Buharov <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: Thomas Munro <[email protected]>
Subject: Re: client_connection_check_interval default value
Date: Thu, 5 Feb 2026 17:02:05 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAOYmi+nS69LiUExZF=gGZ+NJU-SCNQ59qJTiWtJw96cDdi9iSg@mail.gmail.com>
	<[email protected]>
	<CAHGQGwHZUmg+r4kMcPYt_Z-txxVX+CJJhfra+qemxKXvAxYbpw@mail.gmail.com>
	<[email protected]>

On Thu, 05 Feb 2026 19:01:52 -0500
Tom Lane <[email protected]> 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

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: client_connection_check_interval default value
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox