From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: In-Place upgrade concept |
Date: | 2007-07-03 10:50:02 |
Message-ID: | 87odit4v8l.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2007-07-03 10:53:53 | Re: Proposal: In-Place upgrade concept |
Previous Message | Pavel Stehule | 2007-07-03 10:01:08 | Re: what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL |