Re: could not open relation 1663/16525/2604: no such file or dir

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannes Dorbath <light(at)theendofthetunnel(dot)de>
Cc: giuseppe(dot)derossi(at)email(dot)it, pgsql-admin(at)postgresql(dot)org
Subject: Re: could not open relation 1663/16525/2604: no such file or dir
Date: 2007-07-11 15:03:10
Message-ID: 25343.1184166190@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hannes Dorbath <light(at)theendofthetunnel(dot)de> writes:
> On 11.07.2007 12:09, giuseppe(dot)derossi(at)email(dot)it wrote:
>> alfter my computer chrashing, when I try to read a table by using pgAdmin I
>> get the following errors:
>> could not open relation 1663/16525/2604
>> could not open relation 1663/16525/2611
>> could not open relation 1663/16525/2604

> 1.) Do backups
> 2.) Disable write caching in your I/O sub system unless it's battery backed.

Yeah. Postgres cannot defend against the filesystem losing entire files.

> Shutdown PG, backup $PGDATA directory, start PG, try REINDEX DATABASE
> <you_db>;. If that doesn't help anything, there are some tools available
> on pg foundry to inspect the raw files in $PGDATA. You might be able to
> get some of your data back using them.

REINDEX won't help get back missing tables :-(. In this case he's
missing at least pg_attrdef and pg_inherits:

regression=# select 2604::regclass;
regclass
------------
pg_attrdef
(1 row)

regression=# select 2611::regclass;
regclass
-------------
pg_inherits
(1 row)

So if this is the *only* damage then he could dump and perhaps manually
reconstruct the missing DEFAULT and INHERITS clauses (if any). The real
problem is that this is likely only the tip of the iceberg :-(

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Jayakumar_Mukundaraju 2007-07-12 04:28:25 PgAgent Job Scheduling-Backup
Previous Message Tom Lane 2007-07-11 14:41:53 Re: 8.2.4 patches?