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.