Re: [INTERFACES] Peculiar behaviour in libpq
От | Tom Lane |
---|---|
Тема | Re: [INTERFACES] Peculiar behaviour in libpq |
Дата | |
Msg-id | 25895.931357126@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Peculiar behaviour in libpq (Tim Allen <tim@proximity.com.au>) |
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: