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
