From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] In-place upgrade |
Date: | 2008-11-05 06:04:41 |
Message-ID: | 87d4ha6746.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Gregory Stark wrote:
>> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>
>> An old page which never goes away. New page formats are introduced for a
>> reason -- to support new features. An old page lying around indefinitely means
>> some pages can't support those new features. Just as an example, DBAs may be
>> surprised to find out that large swathes of their database are still not
>> protected by CRC checksums months or years after having upgraded to 8.4 (or
>> even 8.5 or 8.6 or ...). They would certainly want a way to ensure all their
>> data is upgraded.
>
> Then provide a manual mechanism to convert all pages?
The origin of this thread was the dispute over this claim:
1. You *will* need a function to convert a page from old format to new
format. We do want to get rid of the old format pages eventually, whether
it's during VACUUM, whenever a page is read in, or by using an extra
utility. And that process needs to online. Please speak up now if you
disagree with that.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-11-05 06:30:35 | Re: [WIP] In-place upgrade |
Previous Message | Joshua D. Drake | 2008-11-05 05:51:41 | Re: [WIP] In-place upgrade |