Re: pg_restore causing deadlocks on partitioned tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Domagoj Smoljanovic <domagoj(dot)smoljanovic(at)oradian(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_restore causing deadlocks on partitioned tables
Date: 2020-09-15 00:08:58
Message-ID: 1227398.1600128538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
>> (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?

I wrote a quick patch for this part. It seems pretty safe and probably
could be back-patched without fear. (I also noticed that
ATSimpleRecursion is being unnecessarily stupid: instead of the
demonstrably not-future-proof relkind check, it could test relhassubclass,
which is not only simpler and less likely to need future changes, but
is able to save a scan of pg_inherits in a lot more cases.)

As far as I can tell in some quick testing, this fix is sufficient to
resolve the complained-of deadlock. It'd still be a good idea to fix the
TRUNCATE side of things as well. But that would be hard to back-patch
because removing ri_PartitionCheck, or even just failing to fill it,
seems like a potential ABI break for extensions. So my proposal is
to back-patch this, but address the ResultRelInfo change only in HEAD.

regards, tom lane

Attachment Content-Type Size
avoid-useless-recursion-for-SET-NOT-NULL.patch text/x-diff 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-15 00:14:48 Re: Improving connection scalability: GetSnapshotData()
Previous Message Soumyadeep Chakraborty 2020-09-14 23:28:12 Re: Adding Support for Copy callback functionality on COPY TO api