Skip site navigation (1) Skip section navigation (2)

Re: SO_SNDBUF size is small on win32?

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Yoshiyuki Asaba" <y-asaba(at)sraoss(dot)co(dot)jp>
Cc: <andrew(at)dunslane(dot)net>, <kleptog(at)svana(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SO_SNDBUF size is small on win32?
Date: 2006-06-27 17:49:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
> > From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> >> 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.

For once, I beleive you are :-)
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().

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

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

We have definitly seen weird timing issues sometimes when both client
and server were on Windows, but have been unable to pin it exactly on
what. From Yoshiykis other mail it looks like this could possibly be it,
since he did experience a speedup in the range we've been looking for in
those cases.

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

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


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-27 18:22:32
Subject: posix_fadvise versus old kernels
Previous:From: J. Andrew RogersDate: 2006-06-27 17:13:03
Subject: Re: Table clustering idea

pgsql-patches by date

Next:From: Tom LaneDate: 2006-06-27 18:43:57
Subject: Re: SO_SNDBUF size is small on win32?
Previous:From: Hiroshi SaitoDate: 2006-06-27 17:38:10
Subject: Client build of MSVC6+ patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group