Re: pg_upgrade does not translate tablespace location to new cluster

Поиск
Список
Период
Сортировка
От Guillaume Lelarge
Тема Re: pg_upgrade does not translate tablespace location to new cluster
Дата
Msg-id 1309538569.2011.17.camel@laptop
обсуждение исходный текст
Ответ на Re: pg_upgrade does not translate tablespace location to new cluster  (Olivier LEVESQUE <olevesque3@gmail.com>)
Ответы Re: pg_upgrade does not translate tablespace location to new cluster
Список pgsql-general
On Fri, 2011-07-01 at 18:30 +0200, Olivier LEVESQUE wrote:
> Guillaume,
>
> Thank you for your answer,
>
>
> >> Creating databases in the new cluster
> >> psql:/opt/pgsql/bin/pg_upgrade_dump_globals.sql:38: ERROR:  directory
> >> "/pgqdata/pgserver01/data/tbs_ptest/PG_9.0_201008051" already in use
> >> as a tablespace
> >>
> >
> > That would mean that you have a 9.0 tablespace in
> > the /pgqdata/pgserver01/data/tbs_ptest directory. Is it true? and IIUC
> > your directory layout, it shouldn't.
> >
>
> Yes, you're right.  This directory was here from my last succesfull pg_upgrade.
>
> But the problem is that now, data of the new cluster is scattered
> across two paths which is not what I expected.
>
>
> > The only way is to change the code. It shouldn't be too hard, but is
> > potentially dangerous.
>
> Why dangerous ? It could be an option.
>

I didn't mean the option is dangerous. My point is: I don't think it
would be interesting to add this change to the mainstream pg_upgrade
because the usecase is very limited (others will correct me if I'm
wrong), so the other option is to code it yourself. And this might be
dangerous (because of very limited tests, and so forth).


--
Guillaume
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Olivier LEVESQUE
Дата:
Сообщение: Re: pg_upgrade does not translate tablespace location to new cluster
Следующее
От: Rich Shepard
Дата:
Сообщение: Adding Foreign Key Constraint To Existing Table