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.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
