Hi,What are the correct steps to move an database and from an server running postgreslq 7.4.2 to another running 8.0.3?-- Richard Bortolucci
If they are both up and running and reachable, then you likely just want to do
something as simple as:
pg_dumpall -h old host | psql -h new host template1
That's assuming you want to move all the DBs on the first server to the
second.
NOTE: pg_dumpall cannot dump large objects. If you have
What are the correct steps to move an database and from an server
running postgreslq 7.4.2 to another running 8.0.3?
I'll assume there are two hosts:
- db7, running 7.4.2, on port 5432, and
- db8, running 8.0.3 on port 5432.
The simplest method would be thus:
- Stop the applications
Rich Cullingford wrote:
Well, I was gonna use pg_dumpall to avoid the tedium of individual
dumps, but (gotcha!) pg_dumpall doesn't accept
--use-set-session-authorization (tho' it does run pg_dump!).
It supplies that option automatically.
If I use
pg_dumpall, will pg_restore (with
All,
I did a pg_dumpall in preparation for moving one of our databases from
PG7.3 to PG7.4, but I just realized I have another problem: that DB
(which has served us faithfully for some time) was created for superuser
'postgres,' whilst our new DBs use a superuser name that's aligned with
our
W licie z pon, 15-12-2003, godz. 16:30, Rich Cullingford pisze:
All,
I did a pg_dumpall in preparation for moving one of our databases from
PG7.3 to PG7.4, but I just realized I have another problem: that DB
(which has served us faithfully for some time) was created for superuser
In my opinion, the only thing you need to change is the name of the
superuser in your dump file.
Bruno
Rich Cullingford wrote:
All,
I did a pg_dumpall in preparation for moving one of our databases from
PG7.3 to PG7.4, but I just realized I have another problem: that DB
(which has served
Rich Cullingford [EMAIL PROTECTED] writes:
I did a pg_dumpall in preparation for moving one of our databases from
PG7.3 to PG7.4, but I just realized I have another problem: that DB
(which has served us faithfully for some time) was created for superuser
'postgres,' whilst our new DBs use a
Tom Lane wrote:
Rich Cullingford [EMAIL PROTECTED] writes:
I did a pg_dumpall in preparation for moving one of our databases from
PG7.3 to PG7.4, but I just realized I have another problem: that DB
(which has served us faithfully for some time) was created for superuser
'postgres,' whilst our
Rich Cullingford [EMAIL PROTECTED] writes:
Hmmm, how do you use 7.4 utilities against a 7.3 DB?
pg_dump can dump from prior-release DBs (back to 7.0 at the moment).
Just point it at the older DB's port.
This is a bit tricky when installing from RPMs, since there's no really
easy way to install
Tom Lane wrote:
Rich Cullingford [EMAIL PROTECTED] writes:
Hmmm, how do you use 7.4 utilities against a 7.3 DB?
pg_dump can dump from prior-release DBs (back to 7.0 at the moment).
Just point it at the older DB's port.
This is a bit tricky when installing from RPMs, since there's no really
easy
Rich Cullingford [EMAIL PROTECTED] writes:
Well, I was gonna use pg_dumpall to avoid the tedium of individual
dumps, but (gotcha!) pg_dumpall doesn't accept
--use-set-session-authorization (tho' it does run pg_dump!). If I use
pg_dumpall, will pg_restore (with
Hi all,
we recently upgraded from 6.53 to 7.1.2, and at the same time tried to move
the database to a new filesystem.
However, while the upgrade was 100% successful using pg_dumpall, we see that
postgres is still reading some files from the old file system (though only
updating the new files).
Ewan Leith [EMAIL PROTECTED] writes:
An example is pg_shadow which is read on both file systems whenever someone
seems to authenticate, but only updated on the new file system.
I don't believe it for a minute. Please describe the actual problem
you're having, rather than jumping to
14 matches
Mail list logo
