Re: Upgrading rant.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Upgrading rant.
Дата
Msg-id 11163.1041626276@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Upgrading rant.  (Hannu Krosing <hannu@tm.ee>)
Ответы Re: Upgrading rant.  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Upgrading rant.  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> I don't think the main issues are with file _formats_ but rather with
> system file structures - AFAIK it is a fundamental design decision
> (arguably a design flaw ;( ) that we use system tables straight from
> page cache via C structure pointers,

The system tables are not the problem.  pg_upgrade has shown how we
can have cross-version upgrades no matter how much the system catalogs
change (a good thing too, because we cannot freeze the system catalog
layout without bringing development to a standstill).  A schema-only
dump and restore is cheap enough that there's no real reason to look
for any other solution.

Changes in the on-disk representation of user tables would be harder to
deal with, but they are also much rarer (AFAIR we've only done that
twice: WAL required additions to page and tuple headers, and then there
were Manfred's space-saving changes in 7.3).  And as of 7.3 there is a
version field in page headers, which would in theory allow for a
page-at-a-time update process to work.

There isn't any fundamental reason why we cannot have a pg_upgrade
utility; claiming that there is something wrong with how we handle
catalog changes misses the point.  The point is that *someone would
have to do the work*.  Unless someone wants to step up and volunteer,
there's little value in discussing it.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: python interface
Следующее
От: mlw
Дата:
Сообщение: Re: Threads