parallel restore sometimes fails for FKs to partitioned tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject parallel restore sometimes fails for FKs to partitioned tables
Date
Msg-id 20191005224333.GA9738@alvherre.pgsql
Whole thread Raw
Responses Re: parallel restore sometimes fails for FKs to partitioned tables
List pgsql-hackers
Hello

While playing around I noticed that depending on the number of parallel
workers in pg_restore compared to the number of partitions a table has,
restoring an FK fails because the FK itself is restored before the index
partitions have completed restoring.  The exact conditions to cause the
failure seem to vary depending on whether the dump is schema-only or not.

This can seemingly be fixed by having pg_dump make the constraint depend
on the attach of each partition, as in the attached patch.  With this
patch I no longer see failures.


This patch is a bit weird because I added a new "simple list" type, to
store pointers.  One alternative would be to store the dumpId values for
the partitions instead, but we don't have a dumpId-typed simple list
either.  We could solve that by casting the dumpId to Oid, but that
seems almost as strange as the current proposal.

The other thing that makes this patch a little weird is that we have to
scan the list of indexes in the referenced partitioned table in order to
find the correct one.  This should be okay, as the number of indexes in
any one table is not expected to grow very large.  This isn't easy to
fix because we don't have a bsearchable array of indexes like we do of
other object types, and this already requires some contortions nearby.
Still, I'm not sure that this absolutely needs fixing now.


-- 
Álvaro Herrera                         Developer, https://www.PostgreSQL.org/

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New "-b slim" option in 2019b zic: should we turn that on?
Next
From: Noah Misch
Date:
Subject: Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)