Tim Allen <tim@proximity.com.au> writes:
> No, it's not the 'Z' message. What appears to be happening is that a
> select condition is occurring without there being any data to read from
> the socket. Inside PQconsumeInput(), which is calling pqReadData(), the
> call to recv() returns -1 with errno set to EAGAIN (I gather this is
> implementation dependent, and could be EWOULDBLOCK on some platforms).
> This happens after _every_ result, ie the result from a query gets
> returned, with the data being successfully read when select() says we can,
> and then one extra select condition occurs, with no data to read.
> So the mystery is, why does select() think there is something to read from
> the socket when recv() thinks not?
How odd. That sure sounds like a kernel bug to me.
> I was starting to suspect it could be merely an oddity of Linux's socket
> implementation, but discovered that the same behaviour occurs on SGI/IRIX.
Do you know whether Linux wrote their own Unix-socket code, or just
adopted the Berkeley socket code? This could be a common failure in
a lot of Unixes, if it's actually in the Berkeley code...
> This is a local (Unix domain) socket, btw, so it's not a TCP/IP issue.
Do you see the same behavior if you use a TCP connection?
regards, tom lane