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.
Re: Upgrading rant. |
Список | 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 по дате отправления: