From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum
Date: Mon, 22 Jan 2018 14:47:36 -0500
Message-ID: <8042.1516650456@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+Tgmoar1NhaM1kiOf8UQOAy7QYrO-Ojb=u0ME5Mez99cJe9aA@mail.gmail.com>
References: <E1edhT6-0002lM-3m@gemulon.postgresql.org>
<CA+Tgmoar1NhaM1kiOf8UQOAy7QYrO-Ojb=u0ME5Mez99cJe9aA@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 22, 2018 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> pg_dumpall with --clean will now drop and recreate the "postgres" and
>> "template1" databases in the target cluster, allowing their locale and
>> encoding settings to be changed if necessary, and providing a cleaner
>> way to set nondefault tablespaces for them than we had before. This
>> means that such a script must now always be started in the "postgres"
>> database; the order of drops and reconnects will not work otherwise.
>> Without --clean, the script will not adjust any database-level properties
>> of those two databases (including their comments, ACLs, and security
>> labels, which it formerly would try to set).
> Unless we insert some guard that causes a hard error or at least warns
> the user if they do the wrong thing, this seems extremely likely to
> have people (1) try to dump and restore using pg_dumpall and (2)
> complain when it doesn't work. Actually, it'll work fine if your OS
> username happens to be "postgres", but otherwise not so much.
Not entirely following your concern. The initial DB's name is "postgres"
regardless of the bootstrap superuser's name. If you're thinking of the
case where you do "initdb -U joe" and then try to "psql <pgdumpallscript"
without specifying a target DB name, that would have failed before and
still will, because there's no DB named "joe". Or if there is, the
DROP DATABASE on it would have failed because you're connected to it,
so it doesn't seem like a habit people would've got into.
The only practice that worked before and now will not is
"psql template1 <pgdumpallscript", and even there, the only thing that
really happens is that template1's locale/encoding/tablespace don't
get adjusted from the way initdb left them. Which was true anyway
for the locale/encoding.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum
In-Reply-To: <8042.1516650456@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox