"=?gb18030?B?zqjSu6Hv?=" <270246512@qq.com> writes:
> Do you have update for this issue?
You've done nothing to convince anyone that this isn't local
misconfiguration or process error on your part.
In particular, I still like the theory I offered in
https://www.postgresql.org/message-id/5802.1573657223%40sss.pgh.pa.us
that the permissions on the public schema don't allow your
non-superuser role to access anything in that schema.
Looking closer at the "pg_restore -v" trace you posted in
https://www.postgresql.org/message-id/tencent_5865E10D689BCC05DFD0BC291ED869BEAA05%40qq.com
bolsters this theory, because I see
pg_restore: dropping COMMENT SCHEMA public
pg_restore: dropping SCHEMA public
pg_restore: creating SCHEMA "public"
pg_restore: creating COMMENT "SCHEMA public"
but there's never any later
pg_restore: creating ACL "SCHEMA public"
which there ought to be, and there is when I try to reproduce this.
That means the public schema is ending up with default permissions,
which grant no access to anyone but the owner.
Perhaps this happened because you did the dump or the restore
with -x (--no-privileges). Or possibly that schema's privileges
were manually modified at some earlier point.
In any case, it's fairly hard to believe that you're giving us
a completely accurate statement of facts, because the restore
trace also includes errors like
pg_restore: dropping TABLE pgbench_accounts
pg_restore: [archiver (db)] Error from TOC entry 199; 1259 47945 TABLE pgbench_accounts cm
pg_restore: [archiver (db)] could not execute query: ERROR: table "pgbench_accounts" does not exist
Command was: DROP TABLE public.pgbench_accounts;
It seems very unlikely that you could have gotten that if you
were restoring a dump you'd just created from the same database.
So there are additional moving parts here that you have not
mentioned.
regards, tom lane