On Mon, Aug 12, 2013 at 6:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark <st...@mit.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
