Skip site navigation (1) Skip section navigation (2)

Re: [JDBC] Possible large object bug?

From: Peter Mount <peter(at)retep(dot)org(dot)uk>
To: "Joe Shevland" <shevlandj(at)kpi(dot)com(dot)au>, <pgsql-jdbc(at)postgresql(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [JDBC] Possible large object bug?
Date: 2001-03-29 08:52:05
Message-ID: 5.0.2.1.0.20010329095040.021219b0@mail.retep.org.uk (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-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(at)postgresql(dot)org


In response to

Responses

pgsql-hackers by date

Next:From: MaurizioDate: 2001-03-29 08:53:53
Subject: testing last sanpshot in QNX platform
Previous:From: Marcin KowalskiDate: 2001-03-29 08:35:06
Subject: Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP

pgsql-bugs by date

Next:From: Dirk LutzebaeckDate: 2001-03-29 08:55:09
Subject: Re: INSERT/SELECT with ORDER BY
Previous:From: Marcin KowalskiDate: 2001-03-29 08:35:06
Subject: Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP

pgsql-jdbc by date

Next:From: Peter MountDate: 2001-03-29 08:58:43
Subject: Re: RE: Compiling
Previous:From: Peter MountDate: 2001-03-29 08:50:04
Subject: Re: RE: Compiling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group