pg_restore dbname

Started by PG Bug reporting formalmost 6 years ago2 messagesdocs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/app-pgrestore.html
Description:

"-C
--create

Create the database before restoring into it. If --clean is also
specified, drop and recreate the target database before connecting to it.

With --create, pg_restore also restores the database's comment if any,
and any configuration variable settings that are specific to this database,
that is, any ALTER DATABASE ... SET ... and ALTER ROLE ... IN DATABASE ...
SET ... commands that mention this database. Access privileges for the
database itself are also restored, unless --no-acl is specified.

When this option is used, the database named with -d is used only to
issue the initial DROP DATABASE and CREATE DATABASE commands. All data is
restored into the database name that appears in the archive."

I am finding the opposite happening from that final sentence. When I use
--clean and --create, it is using the database name from the archive during
the DROP and CREATE commands, and using the --dbname argument for the actual
data restore. However, do either things make sense? Shouldn't all of these
commands be executed against the provided database name in the command? How
can I take a backup from my production environment and restore it into my
test environment, if the db names are different?

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: pg_restore dbname

PG Doc comments form <noreply@postgresql.org> writes:

"-C
--create
...
When this option is used, the database named with -d is used only to
issue the initial DROP DATABASE and CREATE DATABASE commands. All data is
restored into the database name that appears in the archive."

I am finding the opposite happening from that final sentence. When I use
--clean and --create, it is using the database name from the archive during
the DROP and CREATE commands, and using the --dbname argument for the actual
data restore.

Well, it'll initially connect to the database named in -d, issue DROP and
CREATE DATABASE commands naming the target database from there, and then
reconnect to the newly-created database to restore its contents. If you
can show that it's not doing that, that'd be grounds for a bug report
(with some backing details).

However, do either things make sense? Shouldn't all of these
commands be executed against the provided database name in the command?

No, because dropping the database one is currently connected to is
disallowed. So --clean/--create *can't* work that way.

How
can I take a backup from my production environment and restore it into my
test environment, if the db names are different?

Don't use --create. Just give the existing target DB name in -d.
(You can use --clean if you want, but it's probably better to
drop and recreate the test DB manually.)

BTW, the behavior in this area changed a bit in v11, so be careful
you are reading docs that correspond to the pg_restore version
you are using. I don't think this specific thing changed, but
the overall division of labor between pg_dump and pg_dumpall
changed.

regards, tom lane