Re: Possible large object bug? - Mailing list pgsql-jdbc
From | Peter Mount |
---|---|
Subject | Re: Possible large object bug? |
Date | |
Msg-id | 5.0.2.1.0.20010329095040.021219b0@mail.retep.org.uk Whole thread Raw |
In response to | Possible large object bug? ("Joe Shevland" <shevlandj@kpi.com.au>) |
Responses |
RE: Possible large object bug?
|
List | pgsql-jdbc |
At 10:37 27/03/01 +1000, Joe Shevland wrote: >Hi, > >Semi-topical I hope ;) Yes semi ;-) > I've started using Postgres 7.1 (FreeBSD 4.2-S) and large objects via > JDBC. (postmaster (PostgreSQL) 7.1beta5) I'm forwarding this to the bugs list as it looks like something nasty in the back end. >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 majordomo@postgresql.org
pgsql-jdbc by date: