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.

I am a little bit surprised to hear the response. I'm talking about
one of the client programs that are part of PostgreSQL. IMO they
should satisfy higher standard than other PostgreSQL application
programs in error control and signal handling.

> 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).

I'm not sure if it's a duty of libpq. Different applications need to
behave differently when catching signals. I think It would be better
to leave the job for applications.

> 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 think in some cases reading from socket is not reliable enough to
detect a broken socket. Writing to the socket is more reliable. For
this prupose Pgpool-II periodically sends "parameter status" packet to
frontend while waiting for response from backend to detect the socket
is broken or not. Probably PostgreSQL backend could do similar thing.

> 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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp