From: | Mark Stosberg <mark(at)summersault(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Addressing: ERROR: could not access status of transaction |
Date: | 2006-07-07 14:44:17 |
Message-ID: | e8ls1k$5k0$1@sea.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
PostgreSQL has been providing reliable service for our web hosting
company since 1997. Thanks!
Last night we got the following error during a dump of an 8.0.6
database:
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: could not access status of
transaction 245900066
DETAIL: could not open file "/usr/local/pgsql/data/pg_clog/00EA": No
such file or directory
pg_dump: The command was: SELECT tableoid, oid, oprname, oprnamespace,
(select usename from pg_user where oprowner = usesysid) as usename,
oprcode::oid as oprcode FROM pg_operator
Another dump run during the same time frame did not have this problem,
and running the mentioned command in 'psql' produces no error.
Research shows that this could be a corrupted tuple, but it's not
clear what it means to me if it sometimes work.
This follows behavior in the past few days where we noticed PostgreSQL
core dumping repeatedly, with this error:
PANIC: right sibling's left-link doesn't match
The core dumps stopped when we REINDEX'ed the table mentioned in the
PANIC statement.
We were already planning to upgrade to 8.1.x Real Soon.
Are their further insights about this new error? And is my expectation
correct that a full/dump restore into 8.1.x would address it?
Thanks!
Mark
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
mark(at)summersault(dot)com Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-07-07 14:53:14 | Re: Need help with quote escaping in exim for postgresql |
Previous Message | Ron Johnson | 2006-07-07 14:37:38 | Re: Long term database archival |