Yoshiyuki Asaba <[EMAIL PROTECTED]> writes: > From: Tom Lane <[EMAIL PROTECTED]> >> It also says that the condition only occurs if the program uses >> non-blocking sockets ... which the backend does not. So this page >> offers no support for the proposed patch.
> WSAEventSelect() sets a socket to nonblocking mode. Yeah, but that socket is only used for inter-backend signaling with small (1 byte, I think) messages. The socket used for communication with the frontend is not in nonblocking mode, unless I'm totally confused. Have you actually measured any performance benefit from this patch, and if so what was the test case? I'm not opposed to the patch if it does something useful, but the info currently available does not suggest that it will help. What I would think might help is a patch on the libpq side (because it *does* use a nonblocking socket) to avoid sending more than 8K per WSASend call. The effect would just be to break a long send into a series of shorter sends, which wouldn't really do anything useful on a well-designed TCP stack, but then this is Windows we're talking about... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org