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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
