Magnus Hagander wrote: > On Oct 28, 2011 5:19 AM, "Bruce Momjian" <br...@momjian.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....
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
