Kevin Houle wrote:
> One more data point. The DBD::Pg 'lo_extract' function works
> fine across SSL. There is no issue with large objects >= 32K
> using 'lo_extract'. So that casts doubt on it being an OpenSSL
> issue. Is there a different code path within libpq.so to move
> data from the server to the client via SSL for lo_extract than
> for lo_read that we can learn from? I'm looking at the code,
> but for the first time.
This looks suspicious.
$ pwd; find . -type f | xargs grep inv_read
/local/kjh/pgRPM/postgresql-7.3.4/src
./backend/libpq/be-fsstubs.c: status = inv_read(cookies[fd], buf, len);
./backend/libpq/be-fsstubs.c: while ((nbytes = inv_read(lobj, buf,
BUFSIZE)) > 0)
./backend/storage/large_object/inv_api.c:inv_read(LargeObjectDesc
*obj_desc, char *buf, int nbytes)
./include/storage/large_object.h:extern int inv_read(LargeObjectDesc
*obj_desc, char *buf, int nbytes);
inv_read(cookies[fd], buf, len) is in lo_read()
inv_read(lobj, buf, BUFSIZE) is in lo_export()
./backend/libpq/be-fsstubs.c:#define BUFSIZE 8192
The lo_export() function loops calling inv_read() until the
entire object is read. The lo_read() function simply passes
the number of bytes to be read to a single invocation of the
inv_read() function. So if I use a length >= 32768 for
lo_read(), it is happily passed to inv_read in an int datatype,
which is 32k.
Seems to me lo_read() should loop around inv_read() using
BUFSIZE like lo_export() does.
Kevin