Thread: Hmmm 8.1 pg_dumpall cannot dump older db's?
I can't seem to dump old db's: -bash-2.05b$ pg_dumpall -s -h database-dev > dump.sql Password: pg_dumpall: could not connect to database "postgres": FATAL: database "postgres" does not exist Seems that it is expecting the new 'postgres' database to exist on old installations? Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Seems that it is expecting the new 'postgres' database to exist on old
> installations?
Ooops :-( Seems like maybe we want it to try postgres and then fall
back to trying template1?
regards, tom lane
>>Seems that it is expecting the new 'postgres' database to exist on old >>installations? > > Ooops :-( Seems like maybe we want it to try postgres and then fall > back to trying template1? No idea :) I haven't followed the new postgres database changes particularly well... Chris
>>Seems that it is expecting the new 'postgres' database to exist on old >>installations? > > Ooops :-( Seems like maybe we want it to try postgres and then fall > back to trying template1? Actually, also ONLY assume postgres is a special database if the backend is 8.1 or higher. We don't want to mess with poor people who have already created a database called 'postgres' in their installation of 7.4, say... Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> Ooops :-( Seems like maybe we want it to try postgres and then fall
>> back to trying template1?
> Actually, also ONLY assume postgres is a special database if the backend
> is 8.1 or higher. We don't want to mess with poor people who have
> already created a database called 'postgres' in their installation of
> 7.4, say...
No, because it's special anyway where the dump will be reloaded. Keep
in mind that the design assumption for pg_dump(all) is always that the
destination database will be current release or higher; frequently the
dump file won't even be parseable by older servers.
The thing that makes this slightly painful is that we can't tell what
version we are dumping *from* until we've connected, and so we cannot
automagically "do the right thing" here. I don't really see any other
way to do it than the try-and-fallback approach.
regards, tom lane
On Thu, Jul 07, 2005 at 23:44:44 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The thing that makes this slightly painful is that we can't tell what > version we are dumping *from* until we've connected, and so we cannot > automagically "do the right thing" here. I don't really see any other > way to do it than the try-and-fallback approach. But after falling back to template1, a version check could be made and if running 8.1 or higher an error message could be displayed.
Bruno Wolff III <bruno@wolff.to> writes:
> But after falling back to template1, a version check could be made and
> if running 8.1 or higher an error message could be displayed.
Once we're connected to template1, we might as well just use it ...
regards, tom lane
Tom Lane wrote: >Bruno Wolff III <bruno@wolff.to> writes: > > >>But after falling back to template1, a version check could be made and >>if running 8.1 or higher an error message could be displayed. >> >> > >Once we're connected to template1, we might as well just use it ... > > > > Agreed. In any case, I thought that dropping the postgres database was supposed to be OK if you wanted to work that way. (I also thought fallback was the way all this was supposed to work anyway). cheers andrew