| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> |
| Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Keepalive |
| Date: | 2024-06-15 23:25:27 |
| Message-ID: | 2753414.1718493927@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> writes:
> Actually, I just tested on it the Linux system. The keep alive event occurred, 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 really 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rui DeSousa | 2024-06-16 06:06:14 | Re: Keepalive |
| Previous Message | Rui DeSousa | 2024-06-15 16:17:04 | Re: Keepalive |