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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers