回复： 回复： 回复： 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
|
| 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
>hi,
>
>
>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
> CREATE DATABASE cmdb OWNER cm WITH TEMPLATE = template0;
> GRANT ALL PRIVILEGES ON DATABASE cmdb to cm;
>
>
>
>2.pop the data to DB.
> pgbench -i -h 127.0.01 -U cm -s 20 -d cmdb
>
>
>3.use the pg_dump to backup the data.
> pg_dump -h 127.0.0.1 -U postgres -d cmdb -p 5432 -Fc -f bk_1
>4.take the restore via pg_restore.
> 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: