Re: killing pg_dump leaves backend process

On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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