Re: Escaping from blocked send() reprised.

Hello,

> > I condiered it but select() frequently (rather in most cases when
> > send() blocks by send buffer exhaustion) fails to predict that
> > following send() will be blocked. (If my memory is correct.) So
> > the final problem would be blocked send()...
>
> My point was to put the socket in non-blocking mode, so that send()
> will return immediately with EAGAIN instead of blocking, if the send
> buffer is full. See WalSndWriteData for how that would work, it does
> something similar.

I confused it with what I did during writing this patch. select()
- blocking send(). Sorry for confusing the discussion. I
understand correctly what you mean and It sounds reasonable.

> >> I agree it's pretty hard to define any reasonable timeout here. I
> >> think it would be fine to just cut the connection; even if you don't
> >> block while sending, you'll probably reach a CHECK_FOR_INTERRUPT()
> >> somewhere higher in the stack and kill the connection almost as
> >> abruptly anyway. (you can't violate the protocol, however)
> >
> > Yes, closing the blocked connection seems one of the most smarter
> > way, checking the occurred interrupt could avoid protocol
> > violation. But the problem for that is that there seems no means
> > to close sockets elsewhere the blocking handle. dup(2)'ed handle
> > cannot release the resource by only itself.
>
> I didn't understand that, surely you can just close() the socket?
> There is no dup(2) involved. And we don't necessarily need to close
> the socket, we just need to avoid writing to it when we're already in
> the middle of sending a message.

My assumption there was select() and *blocking* send(). So the
sentence cited is out of point from the first.

> I'm marking this as Waiting on Author in the commitfest app, because:
> 1. the protocol violation needs to be avoided one way or another, and
> 2. the behavior needs to be consistent so that a single
> pg_terminate_backend() is enough to always kill the connection.

Thank you for the suggestion. I think I can go forward with that
and will come up with new patch.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center