Re: ERROR: could not open relation
| От | Thomas F. O'Connell |
|---|---|
| Тема | Re: ERROR: could not open relation |
| Дата | |
| Msg-id | 5C38136F-72DC-4DCE-BE1A-11EAE3447848@sitening.com обсуждение исходный текст |
| Ответ на | ERROR: could not open relation ("Thomas F. O'Connell" <tfo@sitening.com>) |
| Список | pgsql-general |
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™
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 directoryHere's the output of SELECT version():PostgreSQL 8.0.3 on i686-pc-linux-gnu, compiled by GCC 2.95.4Here's uname -a:Linux <hostname> 2.6.11.8 #8 SMP Tue Jun 21 11:18:03 CDT 2005 i686 unknownJFS 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: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'ConnellCo-Founder, Information ArchitectSitening, LLCStrategic Open Source: Open Your i™110 30th Avenue North, Suite 6Nashville, TN 37203-6320615-260-0005
В списке pgsql-general по дате отправления: