parallel restore sometimes fails for FKs to partitioned tables
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-10-05T22:43:33Z
Lists: pgsql-hackers
Attachments
- dump-fks-parallel.patch (text/x-diff) patch
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/
Commits
-
Fix parallel restore of FKs to partitioned tables
- b304b2b65fde 12.1 landed
- 1752e351639d 13.0 landed