I wrote:
> If memory serves, which it may not given my undercaffeinated state,
> we would not expect there to be a direct dependency link between the
> constraint and the table data "object". What there should be is
> dependencies forcing the data to be restored before the post-data
> boundary pseudo-object, and the constraint after the boundary.
No, that's wrong: the boundary objects only exist inside pg_dump.
Looking more closely, we have a deadlock between data restore
for a partition:
Process 15858: TRUNCATE TABLE ONLY myschema."myTable:2020-09-01";
and adding a PK to what I assume is its parent partitioned table:
Process 15861: ALTER TABLE ONLY myschema."myTable" ADD CONSTRAINT "pk_myTable" PRIMARY KEY ("ID", date);
Since that's an ALTER TABLE ONLY, it shouldn't be trying to touch the
child partitions at all; while the TRUNCATE should only be trying to touch
the child partition. At least, that's what pg_dump is expecting.
However, the deadlock report suggests, and manual experimentation
confirms, that
(1) TRUNCATE on a partition tries to get AccessShareLock on the parent;
(2) ALTER TABLE ONLY ... ADD CONSTRAINT on a partition root tries to get
AccessExclusiveLock on all child partitions, despite the ONLY.
Each of these facts violates pg_dump's expectations about what can be
done in parallel with what. There's no obvious reason why we need such
concurrency-killing locks for these operations, either. So I think
what we have here are two distinct backend bugs, not a pg_dump bug.
regards, tom lane