Re: FATAL: catalog is missing 1 attribute(s) for relid
От | Mark Kirkwood |
---|---|
Тема | Re: FATAL: catalog is missing 1 attribute(s) for relid |
Дата | |
Msg-id | 41E743CA.8000507@coretech.co.nz обсуждение исходный текст |
Ответ на | FATAL: catalog is missing 1 attribute(s) for relid 16396 ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: FATAL: catalog is missing 1 attribute(s) for relid
|
Список | 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
В списке pgsql-hackers по дате отправления: