pg_upgrade project status

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема pg_upgrade project status
Дата
Msg-id 49184B87.5030505@sun.com
обсуждение исходный текст
Ответы Re: pg_upgrade project status  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
In the last week community made decision about pg_upgrade project and its 
implementation. I would like to try summarize this conclusion and I add other 
topic which should be finished for 8.4.

Convert on read has been selected as a good way, because it is not invasive and 
does not limit fresh database. But, this way needs core modification which 
allows to do online in-place upgrade. It means no online in-place upgrade to 8.4 
will be implemented. Sorry about that, but we need move forward and there is not 
easy way without core modification to do it.

As I mentioned manytimes before there are two major issues with convert on read 
and one small issue.

1) Data does not fit on the new page. It will be solve by pre-upgrade check 
which reserve space on each page, before upgrade.

2) No information about TOASTed data in TOAST table. It is problem for example 
when varlena encoding is changed, or heaptupleheader or array data stucture. 
Idea is to add column position into each chunk and also replace chunk ID by data 
offset.

3) Access methods stores "shadow" data into pages - for example metapages or 
hash index has bitmap pages, but there is no information on the page about this 
and page conversion could lost the data. We need mark this pages. Metapage is 
usually first page and it could be hardwired, but hash bitmap can be everywhere.

I suggest to add page flag HAS_EXTRA_CONTENT (give me a better name).

IIRC, somebody suggest to replace HASH bitmap pages with FSM? Any idea?


I hope that I mention all. Please feel free to add more information or correct 
me if I wrong.
    Thanks Zdenek



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

Предыдущее
От: Michael Meskes
Дата:
Сообщение: gram.y=>preproc.y
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Block-level CRC checks