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.


Tue, 27 Mar 2001 10:37:35 +1000
"Joe Shevland" <shevlandj@kpi.com.au>
Possible large object bug?
"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

Mon, 26 Mar 2001 20:00:54 -0500
Tom Lane <tgl@sss.pgh.pa.us>
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


Thu, 29 Mar 2001 09:52:05 +0100
Peter Mount <peter@retep.org.uk>
Re: [JDBC] Possible large object bug?
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
> 


Fri, 30 Mar 2001 08:05:48 +1000
"Joe Shevland" <shevlandj@kpi.com.au>
RE: [JDBC] Possible large object bug?