Joerg Hessdoerfer <Joerg.Hessdoerfer@sea-gmbh.com> writes:
> I've just checked under Linux - works fine. Then i went back to my WIN
> NT box, and double checked libraries. See what i found: i actually
> used a WIN32 build of the libpq - not the cygwin build. When using
> that, everything is fine, too.
OK, thanks for the report.
> As cygwin uses WIN NT's IP stack, that indicates a poor port of libpq
> to WIN32, doesn't it?
No, it means that Microsoft's implementation of the standard socket
calls is broken. There is no way that user-level code should cause
a TCP implementation to drop data in the way you are seeing.
I was originally concerned that libpq itself was dropping data; the
"nonblock mode" code will do that, and you have to be very careful
to pay attention to whether data was actually sent or not. (It's
fundamentally broken because the library itself fails to pay attention
in many places, but I digress.) Since you're not using nonblock mode,
the library is just shoving out bytes with send(), and it's not our
responsibility to throttle the data flow; it's the TCP stack's.
It would seem that the problem is in the API layer that provides
Berkeley socket emulation, not in the underlying stack, but it's
still Microsoft's code.
> Question is, should we bother?
I can't get excited about it, but if you have the time and interest,
please do dig into it.
regards, tom lane