Re: pg_upgrade

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tory M Blue wrote:
> 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!

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

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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux