Re: BUG #14817: pg_dumpall is not generating create database statements

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: alex(at)yuscott(dot)co(dot)uk
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14817: pg_dumpall is not generating create database statements
Date: 2017-09-15 16:08:11
Message-ID: CAKFQuwbMmWqYnvJqqajZC3X=RHu_Y-weJSVoHLLr2wpY4KvRDw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Sep 15, 2017 at 8:20 AM, <alex(at)yuscott(dot)co(dot)uk> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 14817
> Logged by: Alexander Scott
> Email address: alex(at)yuscott(dot)co(dot)uk
> PostgreSQL version: 9.6.5
> Operating system: CentOS Linux release 7.3.1611 (Core)
> Description:
>
> I have a fresh install of 9.6.5 with a default postgres database.
>
> I have REVOKED ALL FROM public, created a couple of roles and 1 initial
> user.
>
> I wanted to take a dump of the entire cluster to store but the output file
> lacks create statements for the databases.

Working as intended (at least per code comments in pg_dumpall.c @1464) -
the only databases that exist (postgres, template0, template1) in your
installation are the default databases. pg_dumpall is assuming that the
target cluster that you will be restoring into will already contain them
(and a freshly created cluster should) and so decides it does not need to
create them itself.

You will probably need to describe a more complete use case, with an actual
failure, in order to convince someone to change this.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message John R Pierce 2017-09-15 18:15:47 Re: Urgent! PGWatch issue
Previous Message Tom Lane 2017-09-15 15:28:34 Re: BUG #14808: V10-beta4, backend abort