Skip site navigation (1) Skip section navigation (2)

Upgrading vldb from 8.4.3 to 9.1.4

From: "Freddie Burgess" <fburgess(at)radiantblue(dot)com>
To: <pgsql-bugs(at)postgresql(dot)org>
Subject: Upgrading vldb from 8.4.3 to 9.1.4
Date: 2012-08-30 18:48:51
Message-ID: 000901cd86e0$19ccc960$4d665c20$ (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
We have successfully upgraded Postgresql from 8.4.3 to 9.1.4 in our
environment, but we have some questions/issues.
Before the upgrade:
Postgres8 data location -- /usr/local/pgsql/data -->
Postgres9 data location -- /opt/PostgreSQL/9.1/data -->
After the upgrade:
Postgres9 (userdb schema) data location -- /usr/local/pgsql/data -->
Postgres9 data location -- /opt/PostgreSQL/9.1/data -->
We successfully moved all of the data files to /u01/fiber/postgres_data in
an effort to have all of the files located in the same area, but we are
currently stuck with regard to the two high level "data location" points:
/usr/local/pgsql/data and /opt/PostgreSQL/9.1/data, which are both soft
links to the fiber channel.
Is there any way in Postgres to re-define the tablespace locations, or is
the only option available to us is to create new tablespaces w/the correct
directory paths and then move all of the objects (i.e. tables, indexes,
etc.) to the new tablespaces?  This would take some time to script due to
the amount of objects we have, but it is doable. Are there any other

How does Postgres moves the objects? Does It makes a copy of the object in
the new location and then deletes the original. If we Multiply by 5.4 TB of
data files, are we looking at an estimated completion time on the same order
of magnitude as the time it takes for us to perform the backup itself, which
takes approximately 5-7 days?

Finally, when is it safe to remove the 8.4.3 objects/directory?



pgsql-bugs by date

Next:From: Bruce MomjianDate: 2012-08-30 19:05:52
Subject: Re: Upgrading vldb from 8.4.3 to 9.1.4
Previous:From: MirrorXDate: 2012-08-30 15:01:41
Subject: Re: hot standby lagging vs warm that is up-to-date

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group