From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_restore 12 "permission denied for schema" errors |
Date: | 2022-10-22 16:20:02 |
Message-ID: | 727e6a26-4b58-0aea-a701-9671b8935410@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/20/22 14:34, Ron wrote:
> On 10/20/22 10:02, Adrian Klaver wrote:
>> On 10/20/22 06:20, Ron wrote:
>>> On 10/20/22 00:12, Tom Lane wrote:
>>> I ran "pg_dumpall --globals-only --no-role-passwords" on the source
>>> instance, and applied it to the new instance before doing the
>>> pg_restore. If I hadn't done that, pg_restore would have thrown
>>> errors on all the GRANT and ALTER TABLE ... OWNER TO statements
>>> embedded in the backup.
>>>
>>
>> Some questions:
>>
>> 1) The backup was from a Postgres 12.x database using a version 12 or
>> higher instance of pg_backup?
>
> pg_dump and pg_restore are 12.11 from RHEL8.
>
>> 3) What if you run without --jobs?
>
> It runs without error. Add "--jobs=2" and the errors appear.
>
Hmm, that is beyond me.
1) I did notice that the pg_restore errors all where; ERROR: permission
denied for schema strans
2) They all occurred during CREATE INDEX or COPY, which would be the
part where --jobs kicks in.
To me it looks like out of order execution where the jobs starting on
their tasks before the main task got done granting permissions. I just
have no idea how that could happen.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Ron | 2022-10-22 16:41:31 | Re: pg_restore 12 "permission denied for schema" errors |
Previous Message | Adrian Klaver | 2022-10-22 15:56:18 | Re: High CPU usage |