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