Re: ERROR: could not open relation

I'm developing a habit of being the most frequent replier to my own
posts, but anyway: I discovered the meaning of 1663, which is the
default tablespace oid.

But I still need help with diagnosis and treatment...

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Jul 13, 2005, at 8:06 PM, Thomas F. O'Connell wrote:

> I have a production database where we just encountered the
> following error:
>
> ERROR: could not open relation 1663/32019395/94144936: No such
> file or directory
>
> Here's the output of SELECT version():
>
> PostgreSQL 8.0.3 on i686-pc-linux-gnu, compiled by GCC 2.95.4
>
> Here's uname -a:
>
> Linux <hostname> 2.6.11.8 #8 SMP Tue Jun 21 11:18:03 CDT 2005 i686
> unknown
>
> JFS is the filesystem.
>
> Interestingly, this isn't a FATAL error, but after it occurred, not
> a single query was working, and, in fact, all queries seemed to
> generate the error. I wasn't present when the error occurred, and
> by the time I became available, the box had been rebooted, and
> pg_autovacuum, which runs by default, had been started. Otherwise,
> everything seems to have come up as expected. I've since killed
> pg_autovacuum.
>
> Is there any way to get more information about why this error
> occurred and what else I might need to do to recover from it?
>
> I saw this post by Tom Lane in a thread from earlier this year:
>
> http://archives.postgresql.org/pgsql-admin/2005-04/msg00227.php
>
> This makes me ask a possibly unrelated question: what is the 1663
> prefix in the relation string? When I examine $PGDATA/base, the
> directories within seem to be those that start after the 1663. As
> in, I see $PGDATA/base/32019395, not $PGDATA/base/1663/32019395.
>
> Anyway, if I do a lookup by oid for 94144936 in pg_class, I don't
> see it. And, clearly, it's not in $PGDATA/base/32019395.
>
> Are the recommendations the same as in the other thread? REINDEX
> DATABASE? (What is a "standalone backend"? A single-user version?)
> Avoid VACUUMing? pg_dump and reload?
>
> The database is currently running. Should I stop it to prevent
> further damage?
>
> --
> Thomas F. O'Connell
> Co-Founder, Information Architect
> Sitening, LLC
>
> Strategic Open Source: Open Your i™
>
> http://www.sitening.com/
> 110 30th Avenue North, Suite 6
> Nashville, TN 37203-6320
> 615-260-0005
>