Re: pg_upgrade

Поиск
Список
Период
Сортировка
От Nicholson, Brad (Toronto, ON, CA)
Тема Re: pg_upgrade
Дата
Msg-id EC55DC235432104F8255702A8D7344D9257002D4@G9W0741.americas.hpqcorp.net
обсуждение исходный текст
Ответ на Re: pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-performance
> -----Original Message-----
> From: Bruce Momjian [mailto:bruce@momjian.us]
> Sent: Monday, December 05, 2011 10:24 AM
> To: Nicholson, Brad (Toronto, ON, CA)
> Cc: Tory M Blue; pgsql-performance@postgresql.org; Magnus Hagander
> Subject: Re: [PERFORM] pg_upgrade
>
> Nicholson, Brad (Toronto, ON, CA) wrote:
> > > You mean moving tablespaces?  That isn't something pg_upgrade deals
> > > with.  If we need docs to move tablespaces, it is a missing piece
> of
> > > our
> > > main docs, not something pg_upgrade would ever mention.
> >
> > If I'm reading the issue correctly, and pg_upgrade gets part way
> through
> > an upgrade then fails if it hits a tablespace - it seems to me like
> > the pg_upgrade should check for such a condition at the initial
> > validation stage not proceed if found.
>
> Checking for all such cases would make pg_upgrade huge and unusable.
> If
> you messed up your configuration, pg_upgrade can't check for every such
> case.  There are thosands of ways people can mess up their
> configuration.

Based on the OP this does not seem like a messed up configuration.  It sounds like the OP used a fully supported core
featureof Postgres (tablespaces) and pg_upgrade failed as a result.  I think having our upgrade utility fail under such
circumstancesis a bad thing. 

Brad.

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade