Re: pg_upgrade project status

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_upgrade project status
Дата
Msg-id 603c8f070901281028n542282e0pc819f959ad844edc@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade project status  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_upgrade project status  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
>>> Right, the dump+initdb+reload approach works quite well in both
>>> pg_upgrade and pg-migrator. I believe the biggest issue with that ATM is
>>> supporting dropped columns, and maybe there's something else, but it's
>>> fairly robust and works across any versions.
>
>> It works but it is not ideal.
>
> Sure, but the other way is just a complete non-starter.  It's enormous
> amounts of work even for simple changes, and it's not hard to think of
> potentially-desirable catalog rearrangements for which it would be
> completely unworkable.

Well, the goal of coding is to make such things easier.  Already the
solution you're advocating has one huge wart: the need to represent
dropped columns in pg_dump output.  It seems optimistic to assume that
there won't be any more, and it seems possible that some change might
happen that requires the wart without the necessary wart actually
getting inserted.  We'll end up testing after the fact to see whether
in-place upgrade has gotten broken, and given that no one was under
any pressure to give it some forethought in advance, the answer will
probably be "yes", at least sometimes...

I'm not dead set against doing it this way, I'm just not sold on it.

...Robert


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How to get SE-PostgreSQL acceptable
Следующее
От: Joshua Brindle
Дата:
Сообщение: Re: How to get SE-PostgreSQL acceptable