Отключите все ограничения и проверки таблиц при восстановлении дампа

Я получил дамп моей базы данных PostgreSQL с:

pg_dump -U user-name -d db-name -f dumpfile

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

psql X -U postgres  -d db-name-b -f dumpfile

Моя проблема заключается в том, что база данных содержит ссылочные ограничения, проверки и триггеры, и некоторые из них (проверки могут показаться особенно) дают сбой во время восстановления, так как информация не загружается в том порядке, в котором эти проверки будут выполнены. Например, вставка строки в таблицу может быть связана с функцией, CHECKвызывающей plpgsqlфункцию, которая проверяет, выполняется ли условие в какой-либо другой несвязанной таблице. Если эта последняя таблица не загружена psqlдо первой, возникает ошибка.

Ниже приведен SSCCE, который создает такую ​​базу данных, которая после сброса pg_dumpне может быть восстановлена:

CREATE OR REPLACE FUNCTION fail_if_b_empty () RETURNS BOOLEAN AS $$
    SELECT EXISTS (SELECT 1 FROM b)
$$ LANGUAGE SQL;

CREATE TABLE IF NOT EXISTS a (
     i              INTEGER                    NOT NULL
);

INSERT INTO a(i) VALUES (0),(1);
CREATE TABLE IF NOT EXISTS b (
    i  INTEGER NOT NULL
);
INSERT INTO b(i) VALUES (0);

ALTER TABLE a ADD CONSTRAINT a_constr_1 CHECK (fail_if_b_empty());

Есть ли способ отключить (из командной строки) все такие ограничения во время восстановления дампа и включить их снова после этого? Я использую PostgreSQL 9.1.

Итак, вы ищите другие таблицы в CHECKограничении .

CHECKограничения должны запускать IMMUTABLEпроверки. То, что проходит ОК для строки за один раз, должно пройти ОК в любое время. Вот как CHECKограничения определены в стандарте SQL. Это также причина этого ограничения ( согласно документации ):

В настоящее время CHECKвыражения не могут содержать подзапросы или ссылаться на переменные, кроме столбцов текущей строки.

Теперь выражениям в CHECKограничениях разрешено использовать функции, даже пользовательские функции. Они должны быть ограничены IMMUTABLEфункциями, но Postgres в настоящее время не применяет это. Согласно этому связанному обсуждению pgsql-хакеров , одной из причин является разрешение ссылок на текущее время, что не IMMUTABLEявляется естественным.

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

Переместите чек из другой таблицы в триггер (это правильный инструмент), и он должен работать с современными версиями Postgres.

PostgreSQL 9.2 или более поздняя версия

Хотя вышеприведенное справедливо для любой версии Postgres, в Postgres 9.2 было добавлено несколько инструментов, которые помогут вам в вашей ситуации:

опция pg_dump --exclude-table-data

Простым решением было бы сбросить базу данных без данных для таблицы-нарушителя с помощью:

--exclude-table-data=my_schema.my_tbl

Затем добавьте только данные для этой таблицы в конце дампа с помощью:

--data-only --table=my_schema.my_tbl

Но могут возникнуть сложности с другими ограничениями на той же таблице. Есть еще лучшее решение :

NOT VALID

Есть NOT VALIDмодификатор для ограничений. Доступно только для ограничения FK в v9.1, но это было расширено до CHECKограничений в 9.2. По документации:

Если ограничение помечено NOT VALID, потенциально длительная начальная проверка, чтобы убедиться, что все строки в таблице удовлетворяют ограничению, пропускается. Ограничение по-прежнему будет применяться против последующих вставок или обновлений [...]

Простой файл дампа postgres состоит из трех «разделов»:

• pre_data
• data
• post-data

^{В Postgres 9.2 также была добавлена ​​возможность раздельного копирования разделов -- section=sectionname, но это не помогло решить проблему.}

Вот где это становится интересным. По документации:

Элементы после данных включают определения индексов, триггеров, правил и ограничений, отличных от проверенных проверочных ограничений . Элементы предварительно данных включают все остальные элементы определения данных.

Жирный акцент мой.
Вы можете изменить нарушающее CHECKограничение на NOT VALID, которое перемещает ограничение в post-dataраздел. Оставьте и воссоздайте:

ALTER TABLE a DROP CONSTRAINT a_constr_1;
ALTER TABLE a ADD  CONSTRAINT a_constr_1 CHECK (fail_if_b_empty()) NOT VALID;

Это должно решить вашу проблему. Вы даже можете оставить ограничение в этом состоянии , поскольку оно лучше отражает то, что оно фактически делает: проверяет новые строки, но не дает никаких гарантий для существующих данных. В NOT VALIDпроверочном ограничении нет ничего плохого . Если вы предпочитаете, вы можете проверить это позже:

ALTER TABLE a VALIDATE CONSTRAINT a_constr_1;

Но затем вы вернетесь к статус-кво анте.

Похоже, это связано с тем, как pg_dumpсоздается дамп. Глядя на реальный дамп, я увидел, что в CHECKфайле дампов присутствовало ограничение с использованием синтаксиса, который является частью CREATE TABLEкоманды:

CREATE TABLE a (
    i integer NOT NULL,
    CONSTRAINT a_constr_1 CHECK (fail_if_b_empty())
);      

Это создает сбой при восстановлении базы данных, поскольку проверка выполняется до того, как в таблице aили таблице bесть какие-либо данные. Однако, если файл дампа отредактирован и CHECKдобавлен с использованием следующего синтаксиса, в конце файла дампа:

ALTER TABLE a ADD CONSTRAINT a_constr_1 CHECK (fail_if_b_empty()); 

... то в реставрации проблем нет.

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

CREATE OR REPLACE FUNCTION fail_if_b_empty (
    ) RETURNS BOOLEAN AS $$
    SELECT EXISTS (SELECT 1 FROM b)
$$ LANGUAGE SQL;

DROP TABLE IF EXISTS a;

CREATE TABLE IF NOT EXISTS a (
    i   INTEGER   NOT NULL
);

INSERT INTO a(i) VALUES (0),(1);

CREATE TABLE IF NOT EXISTS b (
    i  INTEGER NOT NULL
);

INSERT INTO b(i) VALUES (0);

CREATE TRIGGER tr1 AFTER INSERT OR UPDATE ON a
FOR EACH ROW
EXECUTE PROCEDURE fail_if_b_empty();  

В этом случае, однако, pg_dumpсоздается (по умолчанию) триггер в конце файла дампа (а не в CREATE TABLEоператоре, как в случае проверки), и поэтому восстановление завершается успешно.