Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA32535 for ; Wed, 7 Jul 1999 10:20:03 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA25897; Wed, 7 Jul 1999 10:18:46 -0400 (EDT) To: Tim Allen cc: pgsql-interfaces@hub.org Subject: Re: [INTERFACES] Peculiar behaviour in libpq In-reply-to: Your message of Wed, 7 Jul 1999 14:53:17 +1000 (EST) Date: Wed, 07 Jul 1999 10:18:46 -0400 Message-ID: <25895.931357126@sss.pgh.pa.us> From: Tom Lane Tim Allen 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