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 backend process 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're development db's, that frequent dropping/recreating of tables is maybe causing the prob? The same vacuum commands have run fine before, both from cron and the command line, the only difference was slightly heavier dropping/recreating yesterday.

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 give any 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.