Как удалить внешние ключи, если таблица, в которой они находятся, не существует?

Сценарий:

DELETE FROM table_x WHERE id not in (1,2,3,4)

Ответ:

обновление или удаление в таблице "table_x" нарушает ограничение внешнего ключа "fk1" в таблице "table_y" ПОДРОБНЕЕ: на ключ (table_x_id)=(7) по-прежнему ссылаются из таблицы "table_y".

  • очистил 'table_y' от всех записей
  • FK не отображался в списке FK для «table_y»
  • полностью удалил таблицу 'table_y'

Мы по-прежнему получаем это сообщение, так что предполагается, что где-то в таблице pg_constraints есть ложная запись. В поисках ограничения «fk1» мы находим две записи и удаляем их.

Запрос:

delete from pg_constraint where conname = 'fk1'

Теперь мы получаем ЭТУ ошибку:

[Err] ОШИБКА: не удалось выполнить поиск в кэше для ограничения 868152

На данный момент я совершенно уверен, что нам нужно очистить некоторые записи, но не знаю, как - у кого-нибудь есть опыт в этом, который мог бы указать мне правильное направление?


postgresql corruption postgresql-8.4
person Bradley    schedule 23.07.2012    source источник
comment
VACUUM в последнее время?   -  person Matt Ball    schedule 24.07.2012

Ответы (1)


arrow_upward
0
arrow_downward

Это похоже на плохой индекс. Обратите внимание, что решения здесь являются частичными. Нужно выяснить, в чем первопричина. Причины, которые я видел в прошлом, включают отказ жестких дисков и оперативной памяти, а также перегрев или отказ процессора.

Ограничения внешнего ключа затрагивают уникальные индексы. Если вы наблюдаете здесь странное поведение, проблема может заключаться в плохом индексе. Попробуйте переиндексировать задействованные таблицы или даже целые базы данных, чтобы избавиться от проблемы.

Не думаю, что это из-за отсутствия пылесоса. Закрытие xid неприятно, когда это происходит, но последние версии делают все возможное, чтобы этого не произошло. Скорее всего, это в лучшем случае повреждение индекса. Если нет, то это повреждение данных (обратите внимание, что повреждение индекса происходит гораздо чаще в IME, но повреждение данных происходит по тем же причинам, поэтому найдите корень проблемы).

person Chris Travers    schedule 05.04.2013