Possible large object bug?

Started by Joe Shevlandabout 25 years ago4 messageshackersbugs

shevlandj@kpi.com.au

about 25 years ago

hackersbugs

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.

Tom Lane

tgl@sss.pgh.pa.us

about 25 years ago

In reply to: Joe Shevland (#1)

hackersbugs

Re: [JDBC] 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

Peter T Mount

peter@retep.org.uk

about 25 years ago

In reply to: Joe Shevland (#1)

hackersbugs

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.

Show quoted text

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

Joe Shevland

shevlandj@kpi.com.au

about 25 years ago

In reply to: Peter T Mount (#3)

hackersbugs

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

Show quoted text

-----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