Possible large object bug?

Hi,

Semi-topical I hope ;) I've started using Postgres 7.1 (FreeBSD 4.2-S) and large objects via JDBC. (postmaster
(PostgreSQL)7.1beta5) 

Everything has been working nicely with storing/retrieving blobs, until last night during a vacuum of the database the
backendprocess crashed with the messages added to the end of this email. I'm also using the 'vacuumlo' contributed
code.The order of the cron jobs is: 

59 2  *  *  *  postgres /usr/local/pgsql/bin/vacuumlo -v db1 db2 db3
59 3  *  *  *  postgres /usr/local/pgsql/bin/vacuumdb -z db1
59 4  *  *  *  postgres /usr/local/pgsql/bin/vacuumdb -z db2
59 5  *  *  *  postgres /usr/local/pgsql/bin/vacuumdb -z db3

so I was wondering if there might be a bug in the vacuumlo code (though its vacuumdb dying)? Or I was thinking, because
they'redevelopment db's, that frequent dropping/recreating of tables is maybe causing the prob? The same vacuum
commandshave run fine before, both from cron and the command line, the only difference was slightly heavier
dropping/recreatingyesterday. 

I'm yet to see if that particular database is stuffed as I can recreate and retest easily enough. Let me know if I can
giveany further info, 

Regards,
Joe

---
NOTICE:  Rel pg_attribute: TID 1/115: OID IS INVALID. TUPGONE 1.
...
NOTICE:  Rel pg_attribute: TID 1/6087: OID IS INVALID. TUPGONE 1.
NOTICE:  Rel pg_attribute: TID 1/6111: OID IS INVALID. TUPGONE 1.
NOTICE:  Rel pg_attribute: TID 1/6112: OID IS INVALID. TUPGONE 1.
NOTICE:  Rel pg_attribute: TID 1/6136: OID IS INVALID. TUPGONE 1.
NOTICE:  Rel pg_attribute: TID 1/6137: OID IS INVALID. TUPGONE 1.
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
connection to server was lost
vacuumdb: vacuum  db2 failed
---

with ~500 of the NOTICE lines then the crash. About 1% give a TUPGONE 0 ending instead.