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
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
