On 2016-01-02 22:31, Andres Freund wrote:
On 2016-01-02 22:25:31 +0100, Brar Piening wrote:
Andres Freund wrote:
That seems like a pretty straight forward bug. But it hinges on the
client side calling shutdown() on the socket. I don't know enough about
.net's internals to judge wether it does so. I've traced things far
enough to find
"Disposing a Stream object flushes any buffered data, and essentially
calls the Flush method for you. Dispose also releases operating system
resources such as file handles, network connections, or memory used for
any internal buffering. The BufferedStream class provides the capability
of wrapping a buffered stream around another stream in order to improve
read and write performance."
https://msdn.microsoft.com/en-us/library/system.io.stream%28v=vs.110%29.aspx
which'd plausibly use shutdown().
In the new days of Microsoft you can confirm that even more...
http://referencesource.microsoft.com/#System/net/System/Net/Sockets/Socket.cs,6245
Thanks for digging thatup!
Indeed it does use shutdown(). If I read the npgsql code that'll even be
done in the exception handling path. So fixing the 0 byte case might
already do the trick.
Could any of the windows user try to check whether fixing
if (r != SOCKET_ERROR && b > 0)
/* Read succeeded right away */
return b;
to
if (r != SOCKET_ERROR && b >= 0)
/* Read succeeded right away */
return b;
already does the trick?
Yes it does indeed fix it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
