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

  1. In pg_dump, force reconnection after issuing ALTER DATABASE SET command(s).

  2. Move handling of database properties from pg_dumpall into pg_dump.

  3. Fix pg_dumpall to work for databases flagged as read-only.