2016-08-17 3 views
1

Позвольте мне начать с того, что я администратор Linux/Unix. При этом мой менеджер поручил мне переместить старые базы данных PostgreSQL на сервер RedHat с 8.4.20. Я успешно двигаю 7.2.1 бит, но у меня возникают проблемы с перемещением 7.4.20 дБ.Ошибка создания триггера ограничения

Я использую pg_dump –c filename и psql < filename. Для проблемного db все работает до тех пор, пока я не получу оператор CREATE CONSTRAINT TRIGGER. Если я запускаю его, как это в файле я получаю:

NOTICE: ignoring incomplete trigger group for constraint "" FOREIGN KEY data(ups) REFERENCES upsinfo(ups) DETAIL: Found referenced table's DELETE trigger. CREATE TRIGGER

Если я бегу set schema 'pg_catalog'; я получаю:

ERROR: relation "upsinfo" does not exist

Таблицы (я думаю), вовлеченные:

CREATE TABLE upsinfo (
    ups text NOT NULL, 
    ipaddr inet, 
    rcomm text, 
    wcomm text, 
    reachable boolean, 
    managed boolean, 
    comments text, 
    region text 
); 

CREATE TABLE data (
    date timestamp with time zone, 
    ups text, 
    mib text, 
    value text 
); 

Запрос триггерного запуска триггера:

CREATE CONSTRAINT TRIGGER "<unnamed>" 
    AFTER DELETE ON upsinfo 
    FROM data 
    NOT DEFERRABLE INITIALLY IMMEDIATE 
    FOR EACH ROW 
    EXECUTE PROCEDURE "RI_FKey_cascade_del"('<unnamed>', 'data', 'upsinfo', 'UNSPECIFIED', 'ups', 'ups'); 

Я знаю, что функция RI_FKey_cascade_del определяется по-разному в разных версиях pg_catalog. Обратите внимание, что для параметра search_path установлено значение «public, pg_catalog», поэтому я также смущен, почему мне нужно установить схему.

Снова я не настоящий администратор базы данных PostgreSQL, поэтому старайтесь быть добрым.

ответ

0

Oof, это действительно старые версии постгрейсов, включая версию, которую вы обновляете до версии (8.4 был выпущен в 2009 году, а поддержка закончилась в 2014 году).

Короткий ответ является то, что, до тех пор, как upsinfo и data создаются и заселена, вы, вероятно, хорошо, и хорошо идти. Но одно из ваших отношений с внешним ключом нарушено.

Долгий ответ, ну, позвольте мне посмотреть, могу ли я объяснить, что происходит (или, по крайней мере, то, что я думаю, происходит).

Я предполагаю, что исходное определение таблицы data содержит что-то вроде FOREIGN KEY (ups) REFERENCES upsinfo (ups) ON DELETE CASCADE. Это заставляет postgres автоматически создавать некоторые триггерные ограничения: 1- каждый раз, когда появляется новая строка для data, убедитесь, что ее столбец ups соответствует существующей строке в upsinfo и 2- каждый раз, когда вы удаляете строку из upsinfo, удалите соответствующие строки в data, на основе соответствия ups значения.

Это сообщение (не очень информативное) может возникнуть, если отношения внешнего ключа не работают. Для того, чтобы внешний ключ имел смысл, ссылочное значение должно быть уникальным - должна быть только одна строка в upsinfo для каждого отдельного значения ups. Для того чтобы postgres до знал, что должен быть уникальный индекс или первичный ключ на upsinfo.ups.

В этом случае одна из пары вещей можно было бы разбить его:

  1. Там нет первичного ключа или уникального индекса на upsinfo.ups (Postgres не позволили внешнего ключа, но может иметь очень старых версий)
  2. Там используется как уникальный индекс, но не выполняются должным образом уникальность, поэтому он не получил успешно импортированы (ошибка, снова вероятно из очень старой версии)

в любом случае, , если это отношение внешнего ключа им portant, вы можете попытаться исправить его после завершения импорта. Начните с попытки сделать уникальный индекс на upsinfo.ups и посмотреть, есть ли у вас проблемы. Если вы это сделаете, разрешите дубликаты записей и повторите попытку до тех пор, пока он не будет работать. Затем выпустить что-то вроде:

ALTER TABLE data 
    ADD FOREIGN KEY (ups) REFERENCES upsinfo (ups) ON DELETE CASCADE; 

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

Надеюсь, что это поможет, и удачи!

0

Это, кажется, часть ON DELETE CONSTRAINT. Если бы я был вами, я бы удалил все такие утверждения и заменил их правильным определением ограничений в целевой таблице.

определение таблицы должно выглядеть следующим образом:

CREATE TABLE bookings (
    boo_id serial NOT NULL, 
    boo_hotelid character varying NOT NULL, 
    boo_roomid integer NOT NULL, 
    CONSTRAINT pk_bookings 
     PRIMARY KEY (boo_id), 
    CONSTRAINT fk_bookings_boo_roomid 
     FOREIGN KEY (boo_roomid) 
     REFERENCES rooms (roo_id) MATCH SIMPLE 
     ON UPDATE CASCADE ON DELETE CASCADE 
) WITHOUT OIDS; 

И эта часть, что будет внутренне создать триггер:

CONSTRAINT fk_bookings_boo_roomid 
     FOREIGN KEY (boo_roomid) 
     REFERENCES rooms (roo_id) MATCH SIMPLE 
     ON UPDATE CASCADE ON DELETE CASCADE 

Но, честно говоря, у меня нет понимания для обновление до неподдерживаемой версии. Вы знаете, что Postgres - это версия 9.5, верно?

+0

Спасибо вам за помощь. (И за то, что вы нежны.) Это типичная история: никто не поддерживает программное обеспечение в течение многих лет, а затем внезапно становится все неожиданным. Я попрошу (более как попросить) обновить версию Postgres на новом сервере. –