Re: pg_restore 12 "permission denied for schema" errors
От | Adrian Klaver |
---|---|
Тема | Re: pg_restore 12 "permission denied for schema" errors |
Дата | |
Msg-id | 727e6a26-4b58-0aea-a701-9671b8935410@aklaver.com обсуждение исходный текст |
Ответ на | Re: pg_restore 12 "permission denied for schema" errors (Ron <ronljohnsonjr@gmail.com>) |
Ответы |
Re: pg_restore 12 "permission denied for schema" errors
|
Список | 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.klaver@aklaver.com
В списке pgsql-general по дате отправления: