Re: SO_SNDBUF size is small on win32? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SO_SNDBUF size is small on win32?
Date
Msg-id 26403.1151433837@sss.pgh.pa.us
Whole thread Raw
In response to Re: SO_SNDBUF size is small on win32?  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: SO_SNDBUF size is small on win32?  (Yoshiyuki Asaba <y-asaba@sraoss.co.jp>)
List pgsql-hackers
"Magnus Hagander" <mha@sollentuna.net> writes:
> We use non-blocking sockets in backend/port/win32/socket.c so we are
> able to deliver our "faked signals" while waiting for I/O on the socket.
> We specifically set it in pgwin32_socket().

Hm, that seems a bit grotty, but anyway I stand corrected.

> Given that, it might be a good idea to actually put the code there
> instead, to localise it. With a comment and a reference to that Q
> article.

No, I think the patch has it in the right place, because pgwin32_socket
would have no defensible way of knowing what the max send size would be.
(Indeed, with a slightly different implementation in pqcomm.c, there
would not *be* any hard upper limit; the current code wastes cycles
copying data around, when with a large message it probably should just
send() directly from the message buffer...)

I agree it needs a comment though.

>> 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.

> It could definitly be a good idea to have a patch there *as well*, but I
> think they'd both be affected.

On the libpq side, sending large messages is probably rare except for
COPY IN mode.  Has anyone noticed performance issues specifically with
COPY IN?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: posix_fadvise versus old kernels
Next
From: "Mark Woodward"
Date:
Subject: Re: SO_SNDBUF size is small on win32?