On Thu, Jul 30, 2009 at 7:43 AM, Craig Ringer<craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2009-07-29 at 14:56 +0100, Greg Stark wrote: > >> SIGURG might be useful but it would be more complex to use and less >> widely useful since it would only work if the client disconnects >> gracefully (though it might be worth checking into as an alternative >> to our existing query cancel method). > > Might it not also fire if the client disconnects without notice, but tcp > keepalives are enabled? > > I might have to write a little test program and see. > > [much later] My test program did not appear to receive SIGURB, even > after registering for it with fcntl(sockfd, F_SETOWN, ...) and setting a > signal handler for it. This was the case whether the connection was > dropped due to a tcp keepalive failure, the dropping of a network > interface, or a normal disconnect. The next read() or recv() returned > zero bytes read but no asynchronous notification appeared to occur. I'm > under the impression it's really for use with asynchronous sockets, but > haven't tested this yet. Right, you'll only get SIGURG if there's actually any urgent data received. The client would have to actively send such data periodically. That would make this a portability headache since it wouldn't just be an add-on which would fail gracefully if it's unsupported. The server and client would both have to be sure they understood whether they both supported this feature. > > What does work well is occasionally poking the socket with recv(..., > MSG_DONTWAIT) while doing other work. Program attached. TCP keepalives > seem to work very well at least on my Linux test system, and it's easy > to test for a dud connection using recv(...) with the MSG_DONTWAIT and > (if desired) MSG_PEEK flags. If the connection has exited cleanly it'll > return a zero-size read; if the connection has dropped due to keepalive > failure it'll return ETIMEDOUT. The problem with this is that it introduces spurious failures for transient network failures. Also it requires the server to periodically take time out from processing the query to do this. I think we want a zero-cost method which will interrupt processing if the client actively disconnects. If there's a network failure we'll find out about it in the normal course of events. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
