On Wed, May 12, 2010 at 2:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think what you are describing is a kernel bug. =A0There's not a lot
> we can do about it if the send() call hangs. =A0Considering the kernel
> already knows the connection is closed (per the CLOSE_WAIT state shown
> by netstat) the send() should return failure immediately, and it's not
> doing so.
>
For what it's worth CLOSE_WAIT means the remote end has sent a FIN but
the local end hasn't closed the connection. TCP connections can live
in this half-open state (or its dual) for a while with one direction
closed but the other direction still open. So send() isn't necessarily
going to return an error or anything, it will expect the remote end to
keep receiving data or send an RST if it's actually gone away.
I'm not sure I have a clear idea of the exact scenario from the
description provided. It seems there should be two connections in psql
-> ssh -> postgres and two endpoints for each connection, so I'm not
sure which connections were in CLOSE_WAIT and FIN_WAIT2 and which two
we're still missing.
I'm not sure how ssh behaves when one side closes a connection. It
might not reproduce the half-open connection on the either side
preventing psql/postgres from responding appropriately. I'm not even
sure it's possible for it to do so reliably.
--=20
greg
