АлександрНовик,
Я не уверен, что смогу через форум помочь. Дальше начинается шаманство.
Ваш “critical system index 2662” соответствует системной таблице `pg_class`. Вот пример из моей базы:
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT miss.oid,miss.relname,pg_relation_filenode(miss.oid),
t.oid,t.relname,pg_relation_filenode(t.oid)
FROM pg_class miss
JOIN pg_index i ON i.indexrelid = miss.oid
JOIN pg_class t ON t.oid = i.indrelid
WHERE miss.oid IN (2662, 2671);
oid relname pg_relation_filenode oid relname pg_relation_filenode
---- ------------------------- -------------------- ---- ----------- --------------------
2662 pg_class_oid_index 12766 1259 pg_class 12764
2671 pg_database_datname_index 13001 1262 pg_database 12999
В исходниках, в `src/backend/utils/cache/relcache.c` на 3285 строке начинается функция `RelationCacheInitializePhase3`, она вызывает `load_critical_index` (идёт следом) -- эта и отстреливает. Следуя дальше, приходим в `RelationBuildDesc` (строка 941).
Эта (последняя) функция сканирует `pg_class` чтобы найти описание таблицы. Но т.к. мы ищем информацию о самой `pg_class`, то получается уловка 22.
Копировать файлы откуда-то смысла не имеет, т.к. вам нужен ваш список таблиц, а не сторонний.
Нужно вооружаться каким-нить HEX-редактором, держать формат блоков Postgres'а открытм и смотреть руками, что же там полетело.
Я такими вещами не занимался, это будет долго в любом случае. Если только некоторые биты побиты, то можно что-то подправить. Если данных не хватает кусками, то это будет фатально.
Возможно в интернетах есть утилиты от кого-то из хакеров, которые частично позволяют автоматизировать этот процесс, но придётся собирать из исходников.
Напоследок — я бы не тянул и сразу предупредил начальство, что база упала очень нехорошо и нужно быть готовым к потере данных.
P.S. Может кто-то ещё что сможет подсказать.
P.P.S. Если так всё критично, где же бэкапы?!
