Re: pg_upgrade if 'postgres' database is dropped

On Oct 28, 2011 5:19 AM, "Bruce Momjian" <bruce(at)momjian(dot)us> wrote:
>
> Stephen Frost wrote:
>
> > > > Regarding pg_dumpall and pg_restore, I'm pretty sure both of those
can
> > > > be configured to connect to other databases instead, including for
> > > > globals.
> > >
> > > Well, please show me the code, because the C code I showed you had the
> > > '\connect postgres' string hardcoded in there.
> >
> > I guess there's a difference between "can be used and will work
> > correctly, but might create some extra garbage" and "can't be used at
> > all". pg_dumpall has a -l option for connecting to whatever *existing*
> > database you have to pull the global data, and then it'll restore into a
> > clean initdb'd cluster, after which you could remove postgres.
>
> Keep in mind -l might connect to a specified database to do the dump,
> but it will still connect to the 'postgres' database to recreate them.
>
> > Admittedly, if you initdb the cluster, drop postgres, and then try a
> > restore, it would fail. Personally, I'm not a big fan of that (why
>
> Right, same with pg_upgrade.
>
> > don't we use what was passed in to -l for that..?), but, practically,
>
> No idea.

Chicken/egg? If we did that, the pg_dumpall dump could no longer be loaded
into an empty cluster since the db it wanted to talk to didn't exist yet.
And restoring into an empty cluster has to be the main use for pg_dumpall
after all....

/Magnus