Re: the un-vacuumable table

From: "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Subject: Re: the un-vacuumable table
Date: 2008-07-03 22:16:32
Message-ID: 5a0a9d6f0807031516q7851b3ccoce5276384658487c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2008-07-03 22:16:38 Re: CommitFest rules
Previous Message Tom Lane 2008-07-03 21:37:44 Re: CommitFest rules