I wrote:
> However, the deadlock report suggests, and manual experimentation
> confirms, that
> (1) TRUNCATE on a partition tries to get AccessShareLock on the parent;
The reason for this is that
(a) ExecuteTruncateGuts calls InitResultRelInfo, because it might
need that to fire TRUNCATE triggers for the child relation.
(b) InitResultRelInfo calls RelationGetPartitionQual, which
of course(?) must access the parent table.
AFAICS, it is utterly silly for InitResultRelInfo to be forcing
a partition qual to be computed when we might not need it.
We could flush ResultRelInfo.ri_PartitionCheck altogether and
have anything that was reading it instead do
RelationGetPartitionQual(ResultRelInfo.ri_RelationDesc).
Actually it looks like most of the places reading it are
just interested in non-nullness; can't those be nuked from
orbit in favor of testing rel->rd_rel->relispartition?
There's no such thing as a partition with an empty partition
qual is there? (Or even if it's possible, do we care about
optimizing the case?)
> (2) ALTER TABLE ONLY ... ADD CONSTRAINT on a partition root tries to get
> AccessExclusiveLock on all child partitions, despite the ONLY.
The cause of this seems to be that ATPrepSetNotNull is too dumb to
avoid recursing to all the child tables when the parent is already
attnotnull. Or is there a reason we have to recurse anyway?
regards, tom lane
