On Tue, Sep 15, 2020 at 7:28 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
Yeah, makes sense. Please see attached a patch to do that. -- Amit Langote EnterpriseDB: http://www.enterprisedb.com
remove-ri_PartitionCheck.patch
Description: Binary data
