I wrote:
>>> We could possibly hack something for the special case of rules, but
>>> I don't think this would be the last time we hear about this type of
>>> issue.
BTW, after comparing the dependencies emitted by this patch to those of
HEAD for the regression database, I am convinced that indeed view rules
are not the only issue; we have got a boatload of problems of this ilk,
for instance:
* objects dependent on array types link to an array-type entry that is
not in the dump, not to the base type that is
* composite types link to their underlying "DO_TABLE" entry (ie, the
pg_class entry for the composite type) and thus miss any dependencies
on, say, column data types
* objects dependent on extension members have dangling links; notably,
every single plpgsql function fails to have a visible dependency on the
plpgsql extension
* foreign key constraints have dependencies on PK indexes, but if the PK
index was declared as a constraint, it's not visible under its own ID in
the dump, so the dependency dangles.
The proposed patch fixes all these cases. I am not sure whether any of
the first three are hazards for parallel pg_restore, but the last one
is: AFAICS, it will result in all such FK constraints being restored
serially at the end, because the parallel loop never manages to clear
all of their dependencies. Surprising nobody's complained about that.
regards, tom lane