Magnus Hagander wrote:
> 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
> > > > > 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....
True. My assumption was that they had created some special database
before they did the pg_dumpall restore, but it would be odd because the
database would have been hard-coded into the dump, which isn't good.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ It's impossible for everything to be true. +
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2011-10-28 12:16:58|
|Subject: Re: So, is COUNT(*) fast now?|
|Previous:||From: Bruce Momjian||Date: 2011-10-28 12:12:25|
|Subject: Re: pg_upgrade if 'postgres' database is dropped|