Re: 回复： 回复： 回复： BUG #16101: tables in the DB is not available after pg_restore

On Sun, Nov 17, 2019 at 12:00:31PM -0500, Tom Lane wrote:
>"=?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.
>

Not quite, what seems to make the difference is whether pg_dump was
executed with '-c' switch. Without the switch we end up without ACL.
Consider this:

     $ psql -U postgres -c "CREATE DATABASE cmdb WITH OWNER cm TEMPLATE = template0"
     $ psql -U postgres -c "GRANT ALL PRIVILEGES ON SCHEMA public to cm"

     $ pg_dump -U postgres -d cmdb -Fc -f cmdb.dump -v
     $ pg_restore -U postgres -d cmdb cmdb.dump -c -v
     pg_restore: connecting to database for restore
     pg_restore: dropping COMMENT EXTENSION plpgsql
     pg_restore: dropping EXTENSION plpgsql
     pg_restore: dropping COMMENT SCHEMA public
     pg_restore: dropping SCHEMA public
     pg_restore: creating SCHEMA "public"
     pg_restore: creating COMMENT "SCHEMA public"
     pg_restore: creating EXTENSION "plpgsql"
     pg_restore: creating COMMENT "EXTENSION plpgsql"

     $ dropdb cmdb
     $ psql -U postgres -c "CREATE DATABASE cmdb WITH OWNER cm TEMPLATE = template0"
     $ psql -U postgres -c "GRANT ALL PRIVILEGES ON SCHEMA public to cm"

     $ pg_dump -U postgres -d cmdb -Fc -c -f cmdb.dump -v
     $ pg_restore -U postgres -d cmdb cmdb.dump -c -v

     pg_restore: connecting to database for restore
     pg_restore: dropping COMMENT EXTENSION plpgsql
     pg_restore: dropping EXTENSION plpgsql
     pg_restore: dropping ACL SCHEMA public
     pg_restore: dropping COMMENT SCHEMA public
     pg_restore: dropping SCHEMA public
     pg_restore: creating SCHEMA "public"
     pg_restore: creating COMMENT "SCHEMA public"
     pg_restore: creating EXTENSION "plpgsql"
     pg_restore: creating COMMENT "EXTENSION plpgsql"
     pg_restore: creating ACL "SCHEMA public"


>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.
>

Yeah, there's a fair amount of noise in this thread :-(


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services