Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Advertising
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.
Speaking of on-the-fly upgrading, ReadBuffer is already passed the
Relation, which contains the TupleDesc, so I don't think that's a
problem. Not sure how easy that would be to do in an external program
like pg_migrator.
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.
My thinking is that when a page in the old format is read in, it's
converted to the new format before doing anything else with it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
