Ваша база данных postgres повреждена. oid 2696 — это зарезервированный системой oid, поэтому это системная таблица, и их oids стабильны в разных базах данных и разных версиях. Глядя на мой 9.4, это:
regress=> select relname from pg_class where oid = 2696;
relname
----------------------------------
pg_statistic_relid_att_inh_index
(1 row)
regress=> \d pg_statistic_relid_att_inh_index
Index "pg_catalog.pg_statistic_relid_att_inh_index"
Column | Type | Definition
------------+----------+------------
starelid | oid | starelid
staattnum | smallint | staattnum
stainherit | boolean | stainherit
unique, btree, for table "pg_catalog.pg_statistic"
поэтому у вас есть отсутствующий файл в каталоге данных для индекса pg_statistic_relid_att_inh_index в системной таблице pg_catalog.pg_statistic.
Этого не должно происходить. У вас есть как минимум ограниченное повреждение данных в вашем каталоге данных.
Ваше первое действие должно состоять в том, чтобы остановить базу данных и сделать полную копию всего каталога данных на уровне файловой системы согласно PostgreSQL. вики - коррупция.
Затем проверьте возможные причины. Недавние проблемы с диском? Неожиданное/внезапное завершение работы с последующим fsck, возможно, в системе с небезопасной файловой системой, небезопасными параметрами монтирования (например, ext3/ext4 data=writeback), небезопасными конфигурациями, такими как ext[34]-on-LVM-on-md с барьерами на более старых ядра и т. д. Также убедитесь, что вы используете последнюю версию 8.4.
Только после того, как вы сделали полную копию каталога данных на уровне файловой системы в безопасное хранилище, доступное только для чтения, запустите резервное копирование базы данных (но не приложений, которые ее используют). и посмотрите, можете ли вы подключиться к jiradb, например. psql jiradb. Если можете, незамедлительно выполните pg_dump из jiradb и любых других баз данных с ценными данными.
Не продолжайте использовать поврежденный каталог данных. Сейчас хорошее время для создания дампа и перезагрузки — выполните pg_dumpall --globals-only, pg_dump -Fc каждой базы данных, затем переместите каталог данных в сторону, повторно initdb и начните резервную копию с чистой установкой. Возможно, вы даже захотите одновременно перейти на менее древний PostgreSQL.
Обратите внимание, что, как правило, такие проблемы можно исправить на месте. В этом случае, если ваша поврежденная база данных не была неважной и обычно пустой postgres базой данных, вы можете запустить PostgreSQL в однопользовательском режиме с отключенными системными индексами, а затем REINDEX поврежденный индекс.
person
Craig Ringer
schedule
22.04.2015
