Skip site navigation (1) Skip section navigation (2)

Re: FATAL: catalog is missing 1 attribute(s) for relid

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: FATAL: catalog is missing 1 attribute(s) for relid
Date: 2005-01-14 04:00:10
Message-ID: 41E743CA.8000507@coretech.co.nz (view raw or flat)
Thread:
Lists: pgsql-hackers
Marc G. Fournier wrote:
> 
> 
> What the client did was a 'delete from pg_attribute where ... ' ...
> 
> The database is a 7.4.2 one ... my first thought was one of the older 
> standbys ... rebuild the schema and move the data files into place over 
> top of that ... but of course, 7.3 and beyond are OID based vs name 
> based files, so that doesn't work, unless there is some way of figuring 
> out which file in the old directory corresponds to while oid-file, and 
> without beign able to get into the database to read the system files, 
> thats a wee bit difficult ...
> 
> 

This is probably worth a shot, as I think the catalog oid's are always
the same (can't find the right place in the code to check....), but oid
16396 is pg_am for all the systems here:

# select relname,oid,relfilenode from pg_class where oid like '16396';
  relname |  oid  | relfilenode
---------+-------+-------------
  pg_am   | 16396 |       16396

However, I think it is pg_attribute that you want to rescue - as the
system cannot lookup the attributes for pg_am due to the pg_attribute
deletion:

# select relname,oid from pg_class where relname like 'pg_attribute';
   relname    | oid
--------------+------
  pg_attribute | 1249

You could probably copy 1249 from one of your standbys to your broken
system's PGDATA...(better backup the broken system first, or try the
rescue on another box).

good luck

Mark


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-14 04:01:12
Subject: Re: Bug? 8.0 does not use partial index
Previous:From: Bruce MomjianDate: 2005-01-14 02:38:02
Subject: Re: Has anybody tried porting PostgreSQL to a "stack machine"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group