回复: 回复: 回复: BUG #16101: tables in the DB is not available after pg_restore - Mailing list pgsql-bugs

From 唯一★
Subject 回复: 回复: 回复: BUG #16101: tables in the DB is not available after pg_restore
Date
Msg-id tencent_9BBC6D521745C3B6A62D60F2798F96A5B707@qq.com
Whole thread Raw
In response to Re: 回复: 回复: BUG#16101: tables in the DB is not available after pg_restore  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses 回复: 回复: 回复: BUG #16101: tables in the DB is not available after pg_restore  ("唯一★" <270246512@qq.com>)
List pgsql-bugs

Hi,

 

Thanks for your support.

I saw you take the restore on new DB "cmdb2" and not original DB "cmdb" when taking the backup via pg_dump. My reproduce is use the same DB.

Furthermore, your commands does not specified the username, it will use the same username with environment. it does not reproduce it if use the same users.  

My reproduce is use supper user to take backup and restore. And connect to database with DB owner “cmto” check the tables.

I am sure that it takes the pg_dump and pg_restore on the same system and DB.

Could you reproduce it with the same steps?

 

Thanks

Zeng


------------------ 原始邮件 ------------------
发件人: "Tomas Vondra"<tomas.vondra@2ndquadrant.com>;
发送时间: 2019年11月13日(星期三) 晚上11:18
收件人: "唯一★"<270246512@qq.com>;
抄送: "pgsql-bugs"<pgsql-bugs@lists.postgresql.org>;
主题: Re: 回复: 回复: BUG #16101: tables in the DB is not available after pg_restore

On Wed, Nov 13, 2019 at 10:43:20PM +0800, 唯一★ wrote:
>hi,&nbsp;
>
>
>The restore command is "pg_dump -h 127.0.0.1 -U postgres -d cmdb -p 5432 -Fc -f bk_1"
>Here are reproduce steps.
>1. login in the postgres DB with super user postgres and create DB
>&nbsp;CREATE DATABASE cmdb OWNER cm WITH TEMPLATE = template0;
>&nbsp;GRANT ALL PRIVILEGES ON DATABASE cmdb to cm;
>
>
>
>2.pop the data to DB.
>&nbsp;pgbench -i -h 127.0.01 -U cm -s 20 -d cmdb
>
>
>3.use the pg_dump to backup the data.
>&nbsp;pg_dump -h 127.0.0.1 -U postgres -d cmdb -p 5432 -Fc -f bk_1
>4.take the restore via pg_restore.
>&nbsp;pg_restore -h 127.0.0.1 -U postgres -d cmdb bk_1 -c -v
>

Works just fine for me:

     [user@development ~]$ pg_ctl -D tmp/data init
     ...
     [user@development ~]$ pg_ctl -D tmp/data -l pg.log start
     waiting for server to start.... done
     server started
     [user@development ~]$ createdb cmdb
     [user@development ~]$ pgbench -i -s 1 cmdb
     dropping old tables...
     NOTICE:  table "pgbench_accounts" does not exist, skipping
     NOTICE:  table "pgbench_branches" does not exist, skipping
     NOTICE:  table "pgbench_history" does not exist, skipping
     NOTICE:  table "pgbench_tellers" does not exist, skipping
     creating tables...
     generating data...
     100000 of 100000 tuples (100%) done (elapsed 0.06 s, remaining 0.00 s)
     vacuuming...
     creating primary keys...
     done.
     [user@development ~]$ pg_dump -d cmdb -p 5432 -Fc -f bk_1
     [user@development ~]$ pg_restore -d cmdb2 bk_1 -c -v
     pg_restore: connecting to database for restore
     ...
     pg_restore: warning: errors ignored on restore: 7
     [user@development ~]$ psql cmdb2
     psql (12.1)
     Type "help" for help.

     cmdb2=# \d
                  List of relations
      Schema |       Name       | Type  | Owner
     --------+------------------+-------+-------
      public | pgbench_accounts | table | user
      public | pgbench_branches | table | user
      public | pgbench_history  | table | user
      public | pgbench_tellers  | table | user
     (4 rows)

Are you sure you're running the pg_restore on the right machine and not
on the same system where you did the pg_dump? Don't you have some
per-user search_path setting applied using ALTER USER?

regards

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

pgsql-bugs by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: BUG #16112: large, unexpected memory consumption
Next
From: Mohammad Mostafa Kamal
Date:
Subject: Re: BUG #16046: xpath returns CDATA tag along with the value inpostgres 12