Re: pgsql: Move handling of database properties from pg_dumpall into pg_dum
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-01-22T19:26:06Z
Lists: pgsql-hackers
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
In pg_dump, force reconnection after issuing ALTER DATABASE SET command(s).
- 160a4f62ee7b 11.0 landed
-
Move handling of database properties from pg_dumpall into pg_dump.
- b3f8401205af 11.0 cited
-
Fix pg_dumpall to work for databases flagged as read-only.
- 4bd371f6f886 9.4.0 cited