On Thu, Jul 30, 2009 at 12:22 PM, Craig
Ringer<craig@postnewspapers.com.au> wrote:
>
> In fact, I'm not even sure _how_ one goes about exiting without sending an
> RST. A quick check shows that when I `kill -9' a process with an open client
> socket (ssh, in this case) the OS sends a FIN, and responds to the server's
> FIN,ACK with its own ACK. So the OS is closing the socket for the dead
> process. If I try this with a `psql' process, the server cleans up the
> orphaned backend promptly.
Fwiw this description sounds like you're leaving out part of the picture.
TCP connections consist of two independent flows, one in each
direction. Each flow can be closed by a FIN independently. If the
client program dies and the client sends a FIN to close the
client->server flow that doesn't imply the server will necessarily
close the server->client flow.
For the situation you described to arise the server would have to
notice the EOF on the client connection and explicitly call close.
That would happen if the connection was idle or idle-in-transaction.
If the server was in the middle of running a query then it won't
notice anything until it tries to write to the socket and gets a RST
in response because the listening process has died.
So there are really two different use cases here.
Case 1: the server is idle and reading from a connection and the
client has disappeared completely without closing the connection. In
that case keepalives or having the server try to send data are the
only ways to notice the problem.
Case 2: The server is busy and the client has either cleanly closed
the connection or died but the server doesn't notice for a long time
because it isn't sending any data and it isn't trying to read any data
either.
--
greg
http://mit.edu/~gsstark/resume.pdf