From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rui DeSousa <rui.desousa@icloud.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Keepalive
In-reply-to: <91109DD8-2D2B-41A4-A515-E22295589F35@icloud.com>
References: <161042FE-FC86-456B-A8E1-AED38AE01820@icloud.com>
 <2300378.1718378913@sss.pgh.pa.us>
 <D52B3E92-EA77-4D2D-A39F-B21F65528208@icloud.com>
 <91109DD8-2D2B-41A4-A515-E22295589F35@icloud.com>
Comments: In-reply-to Rui DeSousa <rui.desousa@icloud.com>
	message dated "Fri, 14 Jun 2024 16:32:18 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2753413.1718493927.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 15 Jun 2024 19:25:27 -0400
Message-ID: <2753414.1718493927@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2753414.1718493927%40sss.pgh.pa.us>
Precedence: bulk

Rui DeSousa <rui.desousa@icloud.com> writes:
> Actually, I just tested on it the Linux system.  The keep alive event oc=
curred, the kernel state of the connection went to CLOSE_WAIT and then it =
was later completely removed from the kernel state; however, my spinner() =
function is still running with no network connection in the kernel table.

> So, keep alive does behave differently between FreeBSD and Linux.  I rea=
lly do prefer FreeBSD for many reasons.

The behavior you report for Linux is what I'd expect anywhere.
I tried to replicate your results on a freshly-updated FreeBSD 14.1
installation, and could not.  With a purely stock Postgres
configuration, I see the "spinner" query running indefinitely after
the client is killed --- although the kernel does show the server
process's client connection being in CLOSE_WAIT state.  But if I set
client_connection_check_interval to a positive value then the query
kills itself at the next multiple of that time, again as expected.

So I think there is something non-default about your FreeBSD system.
Maybe you'd previously configured it with nonzero
client_connection_check_interval, and then forgot about that?

The alternative is to suppose that that kernel will kill processes
as soon as they have a connection in CLOSE_WAIT state, which would be
quite evil for many purposes and is certainly not a "preferable"
behavior.

			regards, tom lane