Re: pg_upgrade - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: pg_upgrade
Date
Msg-id 201112051908.pB5J8p905982@momjian.us
Whole thread Raw
In response to Re: pg_upgrade  (Tory M Blue <tmblue@gmail.com>)
List pgsql-performance
Tory M Blue wrote:
> 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!

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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade
Next
From: Scott Marlowe
Date:
Subject: Re: Question about VACUUM