Re: the un-vacuumable table
От | Andrew Hammond |
---|---|
Тема | Re: the un-vacuumable table |
Дата | |
Msg-id | 5a0a9d6f0807031516q7851b3ccoce5276384658487c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: the un-vacuumable table (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: the un-vacuumable table
|
Список | pgsql-hackers |
On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Andrew Hammond" <andrew.george.hammond@gmail.com> writes: >> Does anyone else have any suggestions about what I can do to diagnose this? > > The whole thing is pretty mystifying, especially the ENOSPC write > failure on what seems like it couldn't have been a full disk. Yes, I've passed along the task of explaining why PG thought the disk was full to the sysadmin responsible for the box. I'll post the answer here, when and if we have one. >> Jun 27 15:54:31 qadb2 postgres[92519]: [44-1] PANIC: could not open >> relation 1663/16386/679439393: No such file or directory > > I don't think anyone asked before --- after the restore fails with the > above, does the directory $PGDATA/base/16386/ exist? Although WAL > recovery should attempt to create missing files, I think it won't > try to create missing directories. The directory exists (and the 679439393 file does not). Andrew
В списке pgsql-hackers по дате отправления: