Re: killing pg_dump leaves backend process

On Mon, Aug 12, 2013 at 11:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> That sounds like a mess --- race conditions all over the place, even aside from efficiency worries.

This I don't understand. All I'm envisioning is setting a flag in the
signal handler. If that flag is set then the next CHECK_FOR_INTERRUPTS
would check for eof on the client input anyways (by reading some
additional data into the so any spurious signals due to races would
just be ignored anyways.

It occurs to me it can be kind of tricky to arrange for the
communication layer to actually try to read however. It may have some
data buffered up and choose not to read anything. It's possibly even
going through openssl so we may not even know whether the read
actually happened. Still, at least trying is better than not.


> AFAICS, the POSIX spec doesn't define SIGIO at all, so this worry is
> probably very real.
>
> What I *do* see standardized in POSIX is SIGURG (out-of-band data is
> available).  If that's delivered upon socket close

It's not. You're not going to get SIGURG unless any data is sent with
MSG_OOB. That's not helpful since if the client actually was aware it
was about to exit it could have happily done the existing query cancel
dance. (We could use MSG_OOB and SIGURG instead of our existing query
cancel tricks which might be simpler but given we already have the
existing code and it works I doubt anyone's going to get excited about
experimenting with replacing it with something that's rarely used and
nobody's familiar with any more.)

I do think it's worth making it easy for clients to send a normal
cancel whenever they exit normally. That would probably cover 90% of
the actual problem cases.

> Of course the elephant in the room is Windows --- does it support
> any of this stuff?

I suspect there are three different competing APIs for doing this on
Windows, none of which is spelled the same as Unix but are all better
in various subtly different ways.

-- 
greg