Re: Proposal: In-Place upgrade concept

Gregory Stark wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)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.

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