Re: pg_upgrade - Mailing list pgsql-performance

On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue <tmblue@gmail.com> wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian <bruce@momjian.us> 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$