Thread
-
Possible large object bug?
Joe Shevland <shevlandj@kpi.com.au> — 2001-03-27T00:37:35Z
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. -
Re: [JDBC] Possible large object bug?
Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T01:00:54Z
"Joe Shevland" <shevlandj@kpi.com.au> writes: > Semi-topical I hope ;) Completely irrelevant to JDBC as far as I can see. I've redirected to pghackers. > 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. Ugh. It looks like something has clobbered your pg_attribute file. Was this the first sign of trouble? Can you provide an "od -x" dump of that file? (It'd be $PGDATA/base/DB2OID/1249; you'll need to look in pg_database to determine the OID of db2.) regards, tom lane
-
Re: [JDBC] Possible large object bug?
Peter T Mount <peter@retep.org.uk> — 2001-03-29T08:52:05Z
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
-
RE: [JDBC] Possible large object bug?
Joe Shevland <shevlandj@kpi.com.au> — 2001-03-29T22:05:48Z
Hi, Tom C. and I exchanged a few emails about the issue offlist; Tom spotted after a while that the PostgreSQL data had been clobbered by the output of my cron job (not possible in normal conditions I guess)... end result being he suspects its a hardware glitch or similar (also had 'wc' dump core that same night during the daily periodic run; I'm choosing cosmic radiation ;). I'm going to upgrade to the latest release and also run up another shinier box and see if things work out, I'm sure they will (digging out a tripwire floppy to make ultra sure nothings changed). As a side issue, could/should the vacuumlo functionality be merged with vacuum? Cheers, Joe > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of Peter Mount > Sent: Thursday, March 29, 2001 6:52 PM > To: Joe Shevland; pgsql-jdbc@postgresql.org > Cc: pgsql-bugs@postgresql.org > Subject: Re: [JDBC] Possible large object bug? > > > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >