Re: pg_upgrade
От | Tory M Blue |
---|---|
Тема | Re: pg_upgrade |
Дата | |
Msg-id | CAEaSS0Z_koUNvwACbfS4g76PqBm_tGnybzd4-WQ+jpkv+n-Lhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-performance |
On Mon, Dec 5, 2011 at 11:08 AM, Bruce Momjian <bruce@momjian.us> 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
В списке pgsql-performance по дате отправления: