Re: Unsuccessful SIGINT

On 4-Dec-06, at 1:43 AM, Albe Laurenz wrote:
>> 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.
The Java process on the client machine that held the connection was
killed off and lsof no longer showed a process with a connection on
port 49333. I waited about 7 hours and the database server still
showed the hung connection from port 49333 of the client. I finally
reboot the client computer, which fixed the problem. I suppose
something lower level than the application process was hanging on to
the connection somehow and lsof couldn't even detect it. The client
is a Mac OS X 10.4.8 box. It would have been nice if I could have
killed the process from the server side as well, but I'm sure there's
a good reason why you can't when it's in this state:
send () from /lib64/libc.so.6
in internal_flush ()
in internal_putbytes ()
in pq_putmessage ()
in pq_endmessage ()
in printtup ()
in ExecutorRun ()
in PortalRunSelect ()

> 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.
The last time I tried a kill -9 on a server process the database
instantly reboot itself and it had to perform some kind of crash
recovery. Is a kill -9 okay in some cases? I suppose a restart of the
database would have worked as well, but that was my last resort.