Andres Freund <and...@anarazel.de> writes:
> I can reproduce the issue though when the connection just is very, very slow
> (high packet loss). Uppon receiving a signal the send returns with EINTR
> uppon
> which point I think a check for interrupts might be placed.
The gdb trace you showed before gave no indication that the send() was
returning, which is why I thought it was a kernel bug (or possibly a
glibc bug, not sure exactly where that behavior is determined).
However, even if it did return, we can't just throw a
CHECK_FOR_INTERRUPTS in there. Abandoning the send() would mean that we
lose message boundary synchronization in the FE/BE protocol, because
there's no way to know how many bytes of the current message got sent.
The only way to get out of it would be to abort the transaction and shut
down the backend without any further attempt to communicate with the
client ... which is a code path that doesn't exist, and even if it did
exist is surely not something that should be invoked by a simple query
cancel.
In general we expect the kernel to tell us when the client connection
has been lost. It appears to me that in this case the kernel failed to
do that in a reasonable fashion.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
