On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote: > On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
