| 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™ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005 |
