Re: Fundamental scheduling bug in parallel restore of partitioned tables - Mailing list pgsql-hackers

From Dimitrios Apostolou
Subject Re: Fundamental scheduling bug in parallel restore of partitioned tables
Date
Msg-id a2164edc-a937-c2d5-23d6-471dbf069a2a@gmx.net
Whole thread Raw
In response to Re: Fundamental scheduling bug in parallel restore of partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fundamental scheduling bug in parallel restore of partitioned tables
List pgsql-hackers
On Mon, 14 Apr 2025, Tom Lane wrote:

> I wrote:
>> Here's a draft patch for this.  It seems to fix the problem in
>> light testing.
>
> I realized that the "repro" I had for this isn't testing the same
> thing that Dimitrios is seeing; what it is exposing looks more like
> a bug or at least a behavioral change due to the v18 work to record
> not-null constraints in pg_constraint [1].  So my patch may fix his
> problem or it may not.  It would be good to have a reproducer that
> fails (not necessarily every time) in v17 or earlier.

Thank you for your work on it.

I only got the "ERROR: deadlock detected" message once, with pg_restore
compiled from master branch. My dump is too large to test it many times on
v17 so I can't tell if it occurs there.

In general I believe that dependency resolution is not optimal, either
there is a deadlock bug or not. It can definitely be improved as work
(mostly post-data) is not parallelized as much as it can.

Anyway if I get the deadlock on v17 I'll update the initial thread.


Thanks,
Dimitris




pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Wrong security context for deferred triggers?
Next
From: Tom Lane
Date:
Subject: Re: bug in stored generated column over domain with constraints.