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.