Re: pg_upgrade

Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue <tmblue(at)gmail(dot)com> wrote:
> > On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian <bruce(at)momjian(dot)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!

See my other email --- this might not be necessary.

---------------------------------------------------------------------------

>
> 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$

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +