On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue <tmblue@xxxxxxxxx> wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote:
>>> But initial response to all this, is umm we have not really made a
>>> dump/restore unnecessary with the latest releases of Postgres than, as
>>> I would have to think that there is a high percentage of users whom
>>> use tablespaces.
>>
>> Yes, but they don't change tablespace locations during the upgrade. In
>> fact, we have had surprisingly few (zero) request for moving
>> tablespaces, and now we are trying to implement this for Postgres 9.2.
>> The normal API will be to have the user move the tablespace before the
>> upgrade, but as I said before, it isn't easy to do now in Postgres.
>
> Okay think here is where I'm confused. "they don't change tablespace",
> okay how are they doing the upgrade? Do they leave the olddatadir in
> the default location and create a new one elsewhere, vs where I'm kind
> of doing the opposite?
Okay right
So changed the symlink in pg_tblspaces, and changed the path inside
the db, and it appears to have worked. These were either the "doh
pieces" or the missing components that you helped point me to. Thank
you!
Tory
-bash-4.0$ /logs-all/temp/pg_upgrade --old-datadir "/data1/db"
--new-datadir "/data/db" --old-bindir "/ipix/pgsql8/bin" --new-bindir
"/ipix/pgsql/bin"
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories ok
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system oid user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Creating catalog dump ok
Checking for prepared transactions ok
Checking for presence of required libraries ok
| If pg_upgrade fails after this point, you must
| re-initdb the new cluster before continuing.
| You will also need to remove the ".old" suffix
| from /data1/db/global/pg_control.old.
Performing Upgrade
------------------
Adding ".old" suffix to old global/pg_control ok
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting new commit clogs ok
Copying old commit clogs to new server ok
Setting next transaction id for new cluster ok
Resetting WAL archives ok
Setting frozenxid counters in new cluster ok
Creating databases in the new cluster ok
Adding support functions to new cluster ok
Restoring database schema to new cluster ok
Removing support functions from new cluster ok
Restoring user relation files
ok
Setting next oid for new cluster ok
Creating script to delete old cluster ok
Checking for large objects ok
Upgrade complete
----------------
| Optimizer statistics are not transferred by pg_upgrade
| so consider running:
| vacuumdb --all --analyze-only
| on the newly-upgraded cluster.
| Running this script will delete the old cluster's data files:
| /data/pgsql/delete_old_cluster.sh
-bash-4.0$
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
