Thread: Idea: quicker abort after loss of client connection

Currently, if the client application dies (== closes the connection),
the backend will observe this and exit when it next returns to the
outer loop and tries to read a new command.  However, we might detect
the loss of connection much sooner; for example, if we are doing a
SELECT that outputs large amounts of data, we will see failures from
send().

We have deliberately avoided trying to abort as soon as the connection
drops, for fear that that might cause unexpected problems.  However,
it's moderately annoying to see the postmaster log fill with
"pq_flush: send() failed" messages when something like this happens.

It occurs to me that a fairly safe way to abort after loss of connection
would be for pq_flush or pq_recvbuf to set QueryCancel when they detect
a communications problem.  This would not immediately abort the query in
progress, but would ensure a cancel at the next safe time in the
per-tuple loop.  You wouldn't get very much more output before that
happened, typically.

Thoughts?  Is there anything about this that might be unsafe?  Should
QueryCancel be set after *any* failure of recv() or send(), or only
if certain errno codes are detected (and if so, which ones)?
        regards, tom lane

On Tue, Jun 05, 2001 at 08:01:02PM -0400, Tom Lane wrote:
> 
> Thoughts?  Is there anything about this that might be unsafe?  Should
> QueryCancel be set after *any* failure of recv() or send(), or only
> if certain errno codes are detected (and if so, which ones)?

Stevens identifies some errno codes that are not significant;
in particular, EINTR, EAGAIN, and EWOULDBLOCK.  Of these, maybe
only the first occurs on a blocking socket.

Nathan Myers
ncm@zembu.com

ncm@zembu.com (Nathan Myers) writes:
> On Tue, Jun 05, 2001 at 08:01:02PM -0400, Tom Lane wrote:
>> Thoughts?  Is there anything about this that might be unsafe?  Should
>> QueryCancel be set after *any* failure of recv() or send(), or only
>> if certain errno codes are detected (and if so, which ones)?

> Stevens identifies some errno codes that are not significant;
> in particular, EINTR, EAGAIN, and EWOULDBLOCK.  Of these, maybe
> only the first occurs on a blocking socket.

We already loop for EINTR.  I'm just wondering what to do after we've
given up retrying.
        regards, tom lane

> It occurs to me that a fairly safe way to abort after loss of connection
> would be for pq_flush or pq_recvbuf to set QueryCancel when they detect
> a communications problem.  This would not immediately abort the query in
> progress, but would ensure a cancel at the next safe time in the
> per-tuple loop.  You wouldn't get very much more output before that
> happened, typically.
> 
> Thoughts?  Is there anything about this that might be unsafe?  Should
> QueryCancel be set after *any* failure of recv() or send(), or only
> if certain errno codes are detected (and if so, which ones)?

Seems like a good idea to set Cancel.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026