Thread: Parallel pg_restore fails to import views with triggers (dependency problem?)
Parallel pg_restore fails to import views with triggers (dependency problem?)
From
Dennis Kögel
Date:
Hi, as far as I currently understand it: When a view has to be dumped as table + rule, and it has triggers, it seems that parallelpg_restore fails to understand that the trigger depends on the rule (at least on 9.5.0 and before). A simple test case (see attachment): # 1) create empty DB with view + trigger && create dump $ dropdb x156353; createdb x156353 && psql -d x156353 -qf 156353.sql && pg_dump -d x156353 -Fc -f x156353.pgdump # 2) create database from that dump, no parallelism: works fine $ dropdb x156353; pg_restore -Cdpostgres -j1 x156353.pgdump # 3) create database from that dump, with -j >1: fails $ dropdb x156353; pg_restore -Cdpostgres -j2 x156353.pgdump pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 2852; 2620 1001120 TRIGGER tr_staff_v postgres pg_restore: [archiver (db)] could not execute query: ERROR: "staff_v" is a table DETAIL: Tables cannot have INSTEAD OF triggers. Command was: CREATE TRIGGER tr_staff_v INSTEAD OF INSERT ON staff_v FOR EACH ROW EXECUTE PROCEDURE tf_staff_v(); - D. P.S.: Thanks to RhodiumToad for making sense of this.
Attachment
Re: Parallel pg_restore fails to import views with triggers (dependency problem?)
From
Tom Lane
Date:
Dennis Kögel <dk@neveragain.de> writes: > as far as I currently understand it: When a view has to be dumped as table + rule, and it has triggers, it seems that parallelpg_restore fails to understand that the trigger depends on the rule (at least on 9.5.0 and before). Yup. Fixed, thanks for the report! regards, tom lane