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. 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. I would actually tend to think libpq should offer a way to easily send a cancel and disconnect message immediately upon exiting or closing the connection *and* the server should periodically poll to check for the connection being cleanly closed to handle kill -9. I'm surprised this is the first time we're hearing people complain about this. I know I've seen similar behaviour from Mysql and thought to myself that represented pretty poor behaviour and assumed Postgres did better. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
