From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade if 'postgres' database is dropped |
Date: | 2011-10-28 13:34:02 |
Message-ID: | CAA-aLv6hJxgfAuctJaqSLwrxj1xbin_RkG=Me68_2-QA9jHDLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 October 2011 14:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Oct 28, 2011 at 8:12 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Yes, that would work, but see my summarization email on this. Using
>> template1 is not a problem for pg_upgrade, it is the modifications to
>> pg_dumpall that are an issue.
>
> I just did a bit of testing on this. It appears that pg_dumpall, if
> given a cluster containing no postgres database, will happily try to
> connect to template1 instead. If template1 isn't available either,
> you can use "-l SOMEDBNAME" to specify the name of another database to
> connect to instead. So there is infinite flexibility there.
>
> But regardless of which database it uses to *generate* the dump, the
> dump itself will *always* contain this, right at the very beginning:
>
> \connect postgres
>
> That line is in fact hard-coded as a literal string in pg_dumpall.c.
> It seems like the easiest fix here might be to just remove that line
> from the dump, because AFAICS it's completely pointless. During the
> time for which that setting is in effect, we're just restoring
> globals, so it shouldn't matter which database we're connected to;
> only that we have a valid connection. So trying to switch the
> connection from whatever the user is connected to currently to
> postgres doesn't accomplish anything useful, but it does make it
> possible for dump restoration to unnecessarily fail.
This was the kind of qualm I had with createdb, which I submitted a
patch for earlier this year:
http://archives.postgresql.org/pgsql-hackers/2011-03/msg00999.php
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Shigeru Hanada | 2011-10-28 13:51:06 | Re: pgsql_fdw, FDW for PostgreSQL server |
Previous Message | Robert Haas | 2011-10-28 13:28:15 | Re: pg_upgrade if 'postgres' database is dropped |