On Sep 10, 2008, at 5:57 AM, Tommy Gildseth wrote:
Tom Lane wrote:
Tommy Gildseth <tommy.gildseth@xxxxxxxxxxx> writes:
Richard Huxton wrote:
Looks like part of your query results being sent. Is it hung in
that one
system-call?
Yes, I left it there for about ~1 hour, and that was all that ever
came.
Seems like you have got a network issue. What does netstat show
for the
status of that connection?
I don't think that a query cancel will blow PG off the send; you'd
probably have to resort to kill -9 on that process (with a consequent
restart of other sessions). It's odd that the kernel hasn't given up
on the connection yet ...
Netstat showed:
netstat -a --tcp -p | grep 49004
tcp 0 44660 dbserver:postgres clientserver:49004 ESTABLISHED
17504/postgres: nav
I went back to the server the client was running on to double check,
and it seems the client process hadn't been killed off when the
application was restarted.
We've got some scheduled downtime tomorrow, so I think I'll just
leave it till then, since it's not causing any problems as far as I
can tell.
For what it's worth, I've run into a situation similar to this with a
client a couple time in the last week or two (I can't say identical as
I don't know all of the details about the client end of your
connection). Using the client port # you can use lsof in addition to
netstat (lsof -i tcp:49004) to track down the client process. In our
case, the client process was a connection made via an ssh tunnel and
was sitting in FIN_WAIT2 status. Killing the client process
individually made everything go away nicely without any kind of extra
downtime necessary.
Erik Jones>, Database Administrator
Engine Yard
Support, Scalability, Reliability
(415) 963-4410 x 260
Location: US/Pacific
IRC: mage2k
