large objects

I realise large objects are liked anymore and that the wire protocol is
changing in 7.4 but I've just posted this message into the PHP documentation:

-- begin
Using php 4.3.0 and PostgreSQL 7.3.1

I can write a simple script in which pg_lo_write seems to always return 1 and not the number of bytes written, as
evidencedby extracting the data through another means.
 

Further more, I can make this pg_lo_write fail, or at least fail to write all the data it's pretty difficult to tell
withoutthe number of bytes written being returned, and not return the false value. In addition to this, the lo resource
hasbeen adjusted so that the oid it contains is 0.
 

Unfortunately, I do not know what exactly the failure mode is, it does seem to be in the ip network communication side
ofPostgreSQL, which is odd since the unix domain comms works fine for this. However, it would have been useful to have
thepg_lo_write() function return as advertised, it would have saved some of the 2 man hours me and the dev. team put
intodiagnosing this problem.
 
-- end

Now, I did a little bit of testing and when doing a \lo_export <oid> <filename>
in psql connected via localhost a SIGPIPE is generated in write() in libc and
psql quit, without printing any message to the terminal. Perhaps interestingly
the file that gets written is always 65536 bytes long. The server log shows:

2003-06-05 14:24:02 LOG:  query: select proname, oid from pg_proc                               where proname =
'lo_open'                        or proname = 'lo_close'                         or proname ='lo_creat'
      or proname = 'lo_unlink'                        or proname = 'lo_lseek'                        or proname =
'lo_tell'                         or proname = 'loread'                          or proname = 'lowrite'
 
2003-06-05 14:24:02 LOG:  duration: 0.002924 sec
2003-06-05 14:24:03 LOG:  pq_recvbuf: recv() failed: Success

fwiw.

The last 4 bytes saved and next 16 bytes that should follow are:

00fffc 74 f3 5f ff d0 d1 c6 b3 eb bb 01 26 d6 b3 51 a9
01000c 68 e5 70 54

Of course it could be way past there the failure point but I thought it worth
including on the off chance.

When I do the same except allowing psql to connect through the unix domain
socket it works. The right number of bytes are returned and cmp shows no
differences to the original.

So, a) is this known? b) what is it? c) is it not going to happen in the new
protocol? and d) does anyone care?


-- 
Nigel J. Andrews