Re: pg_upgrade & tablespaces - Mailing list pgsql-general
| From | Joseph Kregloh |
|---|---|
| Subject | Re: pg_upgrade & tablespaces |
| Date | |
| Msg-id | CAAW2xff5s7NpyM=fYWcyJqqc+uJ5+Ssxe-E-2c8GPKkQu9hcmw@mail.gmail.com Whole thread Raw |
| In response to | Re: pg_upgrade & tablespaces (Adrian Klaver <adrian.klaver@gmail.com>) |
| Responses |
Re: pg_upgrade & tablespaces
(Adrian Klaver <adrian.klaver@gmail.com>)
|
| List | pgsql-general |
Here is the message on --hackers that explains the above:
http://www.postgresql.org/message-id/20130214052952.GA10606@momjian.us
Let me read into this.
While the upgrade was successful, I find it unusable and leaving me with
a lot of manual labor ahead of me. Because it leaves the old folders
there, which have to be deleted manually. The same with all the other
data files, like postgresql.conf for example. Something that
uninstalling 9.0 doesn't remove. In other words now I am left with a
dirty /usr/local/pgsql/data folder and having to modify the postgres
startup script. Or manually delete all the files and folders I don't
want and reinstall Posgres 9.3 in the default location and create new
symlinks.
Well one of the options in the upgrade process is to move the old installation out of the way into another directory and then install the new version into the default location. That would eliminate the above issues.
No it does not because pg_upgrade doesn't seem to be able to handle tablespaces, which is the problem I have been having all along and I keep on proving it. Below is the error when moving the 9.0 directory with a tablespace:
[pgsql@postgres-93-upgrade /tmp]$ time /opt/bin/pg_upgrade -d /usr/local/pgsql_90/data -D /usr/local/pgsql/data/ -b /usr/local/bin/ -B /opt/bin/ -p 5452 -P 5451
Performing Consistency Checks
-----------------------------
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
Creating dump of global objects ok
Creating dump of database schemas
ok
Checking for presence of required libraries ok
Checking database user is a superuser ok
Checking for prepared transactions ok
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting files from new pg_clog ok
Copying old pg_clog to new server ok
Setting next transaction ID for new cluster ok
Setting oldest multixact ID on new cluster ok
Resetting WAL archives ok
Setting frozenxid counters in new cluster ok
Restoring global objects in the new cluster ok
Adding support functions to new cluster ok
Restoring database schemas in the new cluster
ok
Removing support functions from new cluster ok
Copying user relation files
.../pgsql/data/drupal_dbspace/PG_9.0_201008051/24659/11790
error while copying relation "pg_catalog.pg_largeobject" ("/usr/local/pgsql/data/drupal_dbspace/PG_9.0_201008051/24659/11790" to "/usr/local/pgsql/data/drupal_dbspace/PG_9.3_201306121/16421/12301"): No such file or directory
Failure, exiting
real 0m25.486s
user 0m0.978s
sys 0m2.872s
pgsql-general by date: