Search Postgresql Archives

Re: pg_upgrade & tablespaces

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

 



Here is the message on --hackers that explains the above:

http://www.postgresql.org/message-id/20130214052952.GA10606@xxxxxxxxxx


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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux