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
We have deliberately avoided trying to abort as soon as the connection
drops, for fear that that might cause unexpected problems.
Isn't there the additional worry, that if the backend does not abort,
that the client might not even notice the error (receives the next packet
which happens to be aligned at row boundaries) ?
Thus my understanding would be, that we eighter need to retry the send,
or abort immediately.
If you do the query cancel, and the connection problem was only intermittent
then the client might receive the query cancelled response for which he is not
prepared, no ?
Imho if the backend cannot allways safely abort, that would be a bug, no ?
Andreas
Import Notes
Resolved by subject fallback
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, Pennsylvania 19026