PG 16.3, of a PG 16 pg_dump of a PG 15.7 database.
Here's a sample of the errors from the "pg_restore -v" log, while attached are samples from the postgresql.log file:
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 847489; 0 1814433 TABLE DATA batch_rp4_y2022m08 fis_tap
pg_restore: error: COPY failed for table "batch_rp4_y2022m08": ERROR: permission denied for schema tapschema
LINE 1: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id...
^
QUERY: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 847492; 0 1814598 TABLE DATA batch_rp4_y2022m05 fis_tap
pg_restore: error: COPY failed for table "batch_rp4_y2022m05": ERROR: permission denied for schema tapschema
LINE 1: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id...
^
QUERY: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 847491; 0 1814543 TABLE DATA batch_rp4_y2022m06 fis_tap
pg_restore: error: COPY failed for table "batch_rp4_y2022m06": ERROR: permission denied for schema tapschema
LINE 1: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id...
^
QUERY: SELECT 1 FROM ONLY "tapschema"."lockbox" x WHERE "lockbox_id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x
pg_restore: finished item 847489 TABLE DATA batch_rp4_y2022m08
The only errors were on COPY statements. The tables and indices were all created, and attached to their parent tables.
Individually restoring the tables from the backup succeeded without error.
There's a FK relationship from batch.lockbox_id to lockbox.lockbox_id, but why should that matter, since FK constraints are created after tables are loaded?
But that gets me thinking... table "batch" is doubly-partitioned: first on the "rp" number, and then the batch_rpX tables are partitioned by the process_date. Might the FK on the batch_rp4 table have already been created?