Re: Why does the pg_dumpall command have a database option?

From: Espresso Beanies <espressobeanies(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Why does the pg_dumpall command have a database option?
Date: 2019-06-21 13:32:19
Message-ID: CAOeD1693QJ6AAT5CaG0u71D+uK3N-5GFGr1H1VnPMeeccrP9xw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Will it still dump all of the databases or just the one it connects to?

On Thu, Jun 20, 2019 at 4:13 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 6/20/19 1:03 PM, Espresso Beanies wrote:
> > I'm trying to see if someone could answer to me why the pg_dumpall
> > command has a database option when it's designed to dump all the
> > databases in a PostgreSQL server instance. I'm only asking because when
> > I create a .pgpass file and try to use the pg_dumpall command, I'm still
> > required to specify a specific database even though the command itself
> > should be targeting all databases. Can anyone explain this to me a bit
> > better?
> >
> > Thanks,
>
> Because pg_dumpall is a client and needs to connect to a database to
> kick start the process/fetch global information:
>
> https://www.postgresql.org/docs/11/app-pg-dumpall.html
>
> -l dbname
> --database=dbname
>
> Specifies the name of the database to connect to for dumping global
> objects and discovering what other databases should be dumped. If not
> specified, the postgres database will be used, and if that does not
> exist, template1 will be used.
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-06-21 13:36:32 Re: Index with new opclass not used for sorting
Previous Message Floris Van Nee 2019-06-21 11:46:10 'too many range table entries' error with partitioned tables and aggregations