Re: Proposal: In-Place upgrade concept

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Proposal: In-Place upgrade concept
Дата
Msg-id 87odit4v8l.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Proposal: In-Place upgrade concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Proposal: In-Place upgrade concept
Список pgsql-hackers
"Heikki Linnakangas" <heikki@enterprisedb.com> writes:

> As before, upgrade can be done, it's just a matter of someone scratching the
> itch. pg_migrator can handle the catalog changes. Doing the page conversion
> from 8.2 -> 8.3 is possible, and it could be done on-the-fly inside PostgreSQL
> the first time a page is read in.

I was previously thinking a convertor for the packed varlena change wouldn't
be necessary since it handles things just fine when it finds a 4-byte header
where a 1-byte header might have been used. I just realized that's not true.

All varlena headers would have to be shifted two bits to the left (on
little-endian machines) and have their toast bits fiddled even if we don't
bother converting them to the shrink their size. Externally toasted varlenas
would however necessarily change size because they must use the new format.

This is actually a bit of a problem. We would need to know when we read in a
page what the tupledescriptor for that relation looks like to know which
fields are varlena. I'm not sure how easy it would be to arrange for the tuple
descriptor to be passed down that far.

Conceivably we could grab another infomask bit to indicate "uses new-style
varlenas" and then have heaptuple.c understand how to convert them in place.
But that leads to a ton of memory management or page locking problems.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



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

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: Re: what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL
Следующее
От: Zdenek Kotala
Дата:
Сообщение: Re: Proposal: In-Place upgrade concept