On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Any other client would behave the same
> > if it were killed while waiting for some backend query. So the right
> > fix would involve figuring out a way for the backend to kill itself
> > if the client connection goes away while it's waiting.
>
> Well I'm not sure. Maybe every other client should also issue a query
> cancel and close the connection if it gets killed. libpq could offer a
> function specifically for programs to call from atexit(), signal
> handlers, or exception handlers (yes, that might be a bit tricky).
>
> But I do see a convincing argument for doing something in the server.
> Namely that if you kill -9 the client surely the server should still
> detect that the connection has gone away immediately.
I agree that both efforts have value. A client-side change can't replace the
server-side change, and tightening the client side will be more of a neatness
measure once the server-side mechanism is in place.
> The problem is that I don't know of any way to detect eof on a socket
> other than trying to read from it (or calling poll or select). So the
> server would have to periodically poll the client even when it's not
> expecting any data. The inefficiency is annoying enough and it still
> won't detect the eof immediately.
Yes, I think that is the way to do it. The check interval could default to
something like 90s, high enough to make the cost disappear into the noise and
yet a dramatic improvement over the current "no fixed time limit".
I bet the utils/timeout.h infrastructure added in 9.3 will make this at least
60% easier to implement than it would have been before.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
