Re: killing pg_dump leaves backend process

On Mon, Aug 12, 2013 at 6:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
>>> 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).
>
>> Do we know how inefficient it is, compared to the baseline work done
>> by CHECK_FOR_INTERRUPTS() and its affiliated machinery?
>
> CHECK_FOR_INTERRUPTS() is about two instructions (test a global variable
> and branch) in the normal case with nothing to do. Don't even think of
> putting a kernel call into it.

So I poked around a bit. It looks like Linux does send a SIGIO when a
tcp connection is closed (with POLL_HUP if it's closed and POLL_IN if
it's half-closed). So it should be possible to arrange to get a signal
which CHECK_FOR_INTERRUPTS could handle the normal way.

However this would mean getting a signal every time there's data
available from the client. I don't know how inefficient that would be
or how convenient it would be to turn it off and on all the time so we
aren't constantly receiving useless signals.

I'm not sure how portal this behaviour is either. There may well be
platforms where having the socket closed doesn't generate a SIGIO.

I'm not sure this is the end of the story either. Ok, so the tcp
stream is closed, does that mean it's safe to end the currently
executing command? There may be a commit buffered up in the stream
that hasn't been processed yet. If you connect and send "vacuum" and
then close the connection do you expect the vacuum to just cancel
immediately?

It does seem obvious that a select shouldn't keep running since it
will die as soon as it produces any output. It may well be that
Postgres should just document it as part of the protocol that if the
tcp connection is closed then whatever command was running may be
terminated at any time since that's effectively true since really any
WARNING or INFO would do that anyways and we don't have any policy of
discouraging those for fear of causing spurious failures.

--
greg