On Mon, Dec 5, 2011 at 11:08 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: > > If you look in a 9.0+ tablespace directory, you will see that each > cluster has its own subdirectory: > > test=> create tablespace tb1 location '/u/pg/tb1'; > CREATE TABLESPACE > test=> \q > $ lf /u/pg/tb1 > PG_9.2_201111231/ > > That means if I upgrade to 9.3, there will be another subdirectory for > 9.3, _inside_ the same tablespace location. This change was added in > Postgres 9.0 to allow for upgrades without having to move tablespaces. > > Now, since you are upgrading from 8.4, and don't have a subdirectory, > the 9.1 cluster will be created inside the tablespace directory, so it > will look like: > > 323234/ 423411/ 932323/ PG_9.1_201105231/ > ---------------- > > I realize that is kind of confusing, but it works just fine, and > pg_upgrade will provide you with a script to delete the old cluster, and > its subdirectories, when you are ready. > > I hope this helps clarify things. > Well I could see the PG_9.1 or whatever directory being created, however I would still get a fail. Once I modified the internal tablespace path and the filesystem symlink, it worked just fine. Having to create 6-10 symlinks is kind of cruddy and altering the paths (although that is not bad). But it's working. So I at least have a method to make this work :) Tory -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
