Strange "permission denied" errors on pg_restore - Mailing list pgsql-admin

From Ron Johnson
Subject Strange "permission denied" errors on pg_restore
Date
Msg-id CANzqJaBrzXfebHJaDLRWenr4WRgvRssTgEQR_O20N0sSv9MHLw@mail.gmail.com
Whole thread Raw
Responses Re: Strange "permission denied" errors on pg_restore
List pgsql-admin
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?
Attachment

pgsql-admin by date:

Previous
From: Wasim Devale
Date:
Subject: Re: Postgresql 12.19 compatible with RHEL 9
Next
From: Imran Khan
Date:
Subject: Re: Postgresql 12.19 compatible with RHEL 9