Re: pg_restore 12 "permission denied for schema" errors
От | Adrian Klaver |
---|---|
Тема | Re: pg_restore 12 "permission denied for schema" errors |
Дата | |
Msg-id | c53708b6-6f90-e73b-5bfe-6568fbeb30bf@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/22/22 14:45, Ron wrote: > On 10/22/22 16:29, Adrian Klaver wrote: >> To pseudo for me. >> >> What file exactly is: >> >> pg_restore --jobs=X --no-owner $NEWDB >> >> restoring? >> >> And how was that file created? >> >> Knowing this might help get at why the more straight forward method >> does not work. > > This is what I ran to restore the database: > export PGHOST=${RDSENV}.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com > cd /migrate/TASK001793786/2022-10-19b > NEWDB=sides > pg_restore -v --create --clean --no-owner --jobs=`nproc` -Fd > --dbname=template1 $NEWDB > psql $NEWDB -f all_OWNER.sql > psql $NEWDB -f all_GRANT.sql > > The name of the database is "sides", and there's a directorynamed > "sides" under /migrate/TASK001793786/2022-10-19b. Aah, I forgot about the -Fd, now it makes more sense. To get past the --jobs induced error required the addition of --no-owner and then adding owners and grants after the main restore. What was the pg_dump command that produced /migrate/TASK001793786/2022-10-19b/sides ? > >>> >>>> >>>>> psql $NEWDB -f all_OWNER.sql >>>>> psql $NEWDB -f all_GRANT.sql >>>>> >>>>> This is, of course, why we need to test the backup/restore process. >>>>> >>>> >>> >> > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: