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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
