Re: Keepalive
От | Rui DeSousa |
---|---|
Тема | Re: Keepalive |
Дата | |
Msg-id | 8CC14391-3C2E-4A0D-A01B-C8F7B6996790@icloud.com обсуждение исходный текст |
Ответ на | Re: Keepalive (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
On Jun 15, 2024, at 7:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:Rui DeSousa <rui.desousa@icloud.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
Yes, I see the same behavior. So trying to figure out why my first test was flawed and I determine Murphy's law is in play. I had an appointment, so I kicked off the query, disconnect the client, when to my appointment, came back and the query was gone. What I didn’t expect was to lose power for few minutes while I was out. I just looked at last command and it reported the server had crashed and rebooted. Hmm.. not knowing why, I also checked the switch it’s connected to and it too rebooted at the same time; so it’s safe to say the system crash do to a power outage. Neither of those are plugged into a UPS; although my firewall is.
I did setup a quick cron job to output the netstat for the connection every minute and didn’t see the four minute gap when I looked at…
.
.
.
Fri Jun 14 14:02:00 EDT 2024
tcp4 0 0 10.6.3.10.5432 10.6.3.44.51478 ESTABLISHED
Fri Jun 14 14:03:00 EDT 2024
tcp4 0 0 10.6.3.10.5432 10.6.3.44.51478 ESTABLISHED
Fri Jun 14 14:04:00 EDT 2024
tcp4 0 0 10.6.3.10.5432 10.6.3.44.51478 ESTABLISHED
Fri Jun 14 14:08:00 EDT 2024
Fri Jun 14 14:09:00 EDT 2024
Fri Jun 14 14:10:00 EDT 2024
Fri Jun 14 14:11:00 EDT 2024
.
.
.
В списке pgsql-admin по дате отправления:
Следующее
От: Veerendra PulapaДата:
Сообщение: Urgent: Segmentation Fault in PostgreSQL postmaster Process