> I have a connection that I am unable to kill with a sigint.
>
> ps auxww for the process in question:
> postgres 3578 0.3 3.6 6526396 1213344 ? S Dec01 0:32
> postgres: postgres ssprod 192.168.0.52(49333) SELECT
>
> and gdb shows:
> (gdb) bt
> #0 0x00002ba62c18f085 in send () from /lib64/libc.so.6
> #1 0x0000000000504765 in internal_flush ()
> #2 0x0000000000504896 in internal_putbytes ()
> #3 0x00000000005048fc in pq_putmessage ()
> #4 0x0000000000505ea4 in pq_endmessage ()
> #5 0x000000000043e37a in printtup ()
> #6 0x00000000004e9349 in ExecutorRun ()
> #7 0x0000000000567931 in PortalRunSelect ()
> #8 0x00000000005685f0 in PortalRun ()
> #9 0x0000000000565ea8 in PostgresMain ()
> #10 0x0000000000540624 in ServerLoop ()
> #11 0x000000000054131a in PostmasterMain ()
> #12 0x000000000050676e in main ()
>
> lsof on the client machine (192.168.0.52) shows no connections on
> port 49333, so it doesn't appear to be a simple matter of killing the
> client connection. If I have to, I can reboot the client machine, but
> this seems like overkill and I'm not certain this will fix the
> problem. Anything else I can try on the server or the client short of
> restarting the database or rebooting the client?
Do I get it right that there is no process on the client machine
using port 49333?
Maybe you can reboot the client machine to make sure.
I'd wait for some time, because the send() might be stuck in kernel
space, and I guess it should timeout at some point. Then the process
will go away.
If the server process is still there after a couple of hours, hmm,
I don't know. Maybe resort to a kill -9. If that does not get rid
of the server process, it is stuck in kernel space for good and
probably nothing except a reboot will get rid of it.
Yours,
Laurenz Albe
