ERROR: could not open relation

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