BUG #14636: pg_dumpall -d

Started by Adrian Klaveralmost 9 years ago3 messagesbugs
Jump to latest
#1Adrian Klaver
adrian.klaver@aklaver.com

The following bug has been logged on the website:

Bug reference: 14636
Logged by: Adrian Klaver
Email address: adrian.klaver@aklaver.com
PostgreSQL version: Unsupported/Unknown
Operating system: Linux openSUSE Leap 42.2
Description:

Pulled the nightly build of Postgres 10:
2017-04-30 20:30:26
Testing dump/restore from a 9.6 instance to the 10 instance. Tried dumping
the globals using pg_dumpall and connected using:
aklaver@tito:~> /usr/local/pgsql10/bin/pg_dumpall -g -d postgres -U postgres
-p 5432 -f production_globals.sql
pg_dumpall: missing "=" after "postgres" in connection info string

This not what I usually do and when I used -l it worked as expected. The bug
is that the docs say:
https://www.postgresql.org/docs/devel/static/app-pg-dumpall.html

"-d connstr
--dbname=connstr

Specifies parameters used to connect to the server, as a connection
string. See Section 33.1.1 for more information.

The option is called --dbname for consistency with other client
applications, but because pg_dumpall needs to connect to many databases,
database name in the connection string will be ignored. Use -l option to
specify the name of the database used to dump global objects and to discover
what other databases should be dumped.
"

Instead an error is raised.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

#2Michael Paquier
michael@paquier.xyz
In reply to: Adrian Klaver (#1)
Re: BUG #14636: pg_dumpall -d

On Mon, May 1, 2017 at 7:08 AM, <adrian.klaver@aklaver.com> wrote:

Pulled the nightly build of Postgres 10:
2017-04-30 20:30:26
Testing dump/restore from a 9.6 instance to the 10 instance. Tried dumping
the globals using pg_dumpall and connected using:
aklaver@tito:~> /usr/local/pgsql10/bin/pg_dumpall -g -d postgres -U postgres
-p 5432 -f production_globals.sql
pg_dumpall: missing "=" after "postgres" in connection info string

This not what I usually do and when I used -l it worked as expected. The bug
is that the docs say:
https://www.postgresql.org/docs/devel/static/app-pg-dumpall.html

"-d connstr
--dbname=connstr

Specifies parameters used to connect to the server, as a connection
string. See Section 33.1.1 for more information.

The option is called --dbname for consistency with other client
applications, but because pg_dumpall needs to connect to many databases,
database name in the connection string will be ignored. Use -l option to
specify the name of the database used to dump global objects and to discover
what other databases should be dumped.
"

Instead an error is raised.

The documentation and the behavior look correct to me. You did not
specify a correct connection string using -d, and just used a database
name. If you want to have a database name ignored in the connection
string defined by -d, you need to use "dbname=postgres".
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

#3Adrian Klaver
adrian.klaver@aklaver.com
In reply to: Michael Paquier (#2)
Re: BUG #14636: pg_dumpall -d

On 04/30/2017 10:45 PM, Michael Paquier wrote:

On Mon, May 1, 2017 at 7:08 AM, <adrian.klaver@aklaver.com> wrote:

Pulled the nightly build of Postgres 10:
2017-04-30 20:30:26
Testing dump/restore from a 9.6 instance to the 10 instance. Tried dumping
the globals using pg_dumpall and connected using:
aklaver@tito:~> /usr/local/pgsql10/bin/pg_dumpall -g -d postgres -U postgres
-p 5432 -f production_globals.sql
pg_dumpall: missing "=" after "postgres" in connection info string

This not what I usually do and when I used -l it worked as expected. The bug
is that the docs say:
https://www.postgresql.org/docs/devel/static/app-pg-dumpall.html

"-d connstr
--dbname=connstr

Specifies parameters used to connect to the server, as a connection
string. See Section 33.1.1 for more information.

The option is called --dbname for consistency with other client
applications, but because pg_dumpall needs to connect to many databases,
database name in the connection string will be ignored. Use -l option to
specify the name of the database used to dump global objects and to discover
what other databases should be dumped.
"

Instead an error is raised.

The documentation and the behavior look correct to me. You did not
specify a correct connection string using -d, and just used a database
name. If you want to have a database name ignored in the connection
string defined by -d, you need to use "dbname=postgres".

Aah, I was not paying attention and did not realize that -d changed
context. Thanks for clearing this up for me. Ignore the report.

--
Adrian Klaver
adrian.klaver@aklaver.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs