Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tomas Berndtsson <tomas@nocrew.org> writes:
> > However, after some semi-random looking through the source code of
> > libpq, I tried to change a value, namely here:
> > fe-misc.c row 510 in pqReadData():
> > if (conn->inEnd > 32768 &&
> > (conn->inBufSize - conn->inEnd) >= 8192)
>
> > I changed the 32768 value to 131072, and sure enough, my application
> > was able to get larger fields without any errors.
>
> That's really interesting. I cannot see anything unsafe about that
> retry loop --- could you instrument it some more to determine exactly
> what happens after we go back to try to read more?
>
> Also, are you using SSL by any chance? Perhaps the problem is that
> the SSL library doesn't react the same as a bare recv() call?
Nope, no SSL.
I inserted some debug printing in the code. This is the output:
LIBPQ: recv inbufsize=16384 inend=0 nread=8192
LIBPQ: recv inbufsize=16384 inend=6194 nread=8192
LIBPQ: recv inbufsize=32768 inend=14386 nread=8192
LIBPQ: recv inbufsize=32768 inend=22578 nread=8192
LIBPQ: recv inbufsize=65536 inend=30770 nread=8192
LIBPQ: trying again
LIBPQ: recv inbufsize=65536 inend=38962 nread=-1
LIBPQ: SOCK_ERRNO = 25 (Inappropriate ioctl for device)
message type 0x44 arrived from server while idle
The "recv" row is printed right after recv is called.
"trying again" is printed inside the
if (conn->inEnd > 32768 && (conn->inBufSize - conn->inEnd) >= 8192)
After it tries again, it always gets error from recv() for some reason
that I don't know. I also don't understand why errno is set to ENOTTY
at this point, that makes no sense at all. But it does, and libpq
doesn't recognise the errno code and therefore returns -1 from
pqReadData().
By skipping the trying again if-statement, pqReadData() will always
return proper data, and let the calling function deal with the fact
that there is more data to be read.
I don't know if I can help you more than this. I have absolutely no
idea why recv() would fail with ENOTTY.
Tomas
