Search Postgresql Archives

Re: Unsuccessful SIGINT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux