Greg Stark wrote:
On Mon, Jan 25, 2010 at 11:37 AM, Herouth Maoz <herouth@unicell.co.il> wrote:
The tcp_keepalive setting would only come into play if the remote
machine crashed or was disconnected from the network.
That's the situation I'm having, so it's OK. Crystal, being a Windows
application, obviously runs on a different server than the database itself,
so the connection between them is TCP/IP, not Unix domain sockets.
The unix socket api is used for both unix domain sockets and internet
domain sockets. The point is that in the api there's no way to find
out about a connection the other side has closed except for when you
write or read from it or when you explicitly check.
And
furthermore, that was exactly the problem as I described it - the fact that
the third party software, instead of somehow instructing Crystal to send a
cancel request to PostgreSQL, instead just kills the client process on the
Windows side.
Killing the client process doesn't mean the machine has crashed or
been disconnected from the network. I'm assuming Crystal isn't
crashing the machine just to stop the report... And even if it did and
tcp_keepalives kicked in the server *still* wouldn't notice until it
checked or tried to read or write to that socket.
Well, I assume by the fact that eventually I get an "Unexpected end of file" message for those queries, that something does go in and check them. Do you have any suggestion as to how to cause the postgresql server to do so earlier?
Herouth