On Tue, Dec 1, 2009 at 7:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 1, 2009 at 2:06 PM, Aidan Van Dyk <aidan@highrise.ca> wrote:
>> Well, *I* think if we're ever going to have really reliable "in-place
>> upgrades" that we can expect to function release after release, we're
>> going to need to be able to read in "old version" pages, and convert
>> them to current version pages, for some set of "old version" (I'ld be
>> happy with $VERSION-1)... But I don't see that happening any time
>> soon...
>
> I agree. I've attempted to make this point before - as has Zdenek -
> and been scorned for it, but I don't think it's become any less true
> for all of that. I don't think you have to look much further than the
> limitations on upgrading from 8.3 to 8.4 to conclude that the current
> strategy is always going to be pretty hit or miss.
I find that hard to understand. I believe the consensus is that an
on-demand page-level migration statregy like Aidan described is
precisely the plan when it's necessary to handle page format changes.
There were no page format changes for 8.3->8.4 however so there's no
point writing dead code until it actually has anything to do. And
there was no point writing it for previously releases because there
was pg_migrator anyways. Zdenek's plan was basically the same but he
wanted the backend to be able to handle any version page directly
without conversion any time.
Pointing at the 8.3 pg_migrator limitations is irrelevant -- every
single one of those limitations would not be addressed by a page-level
migration code path. They are all data-type redefinitions that can't
be fixed without understanding the table structure and definition.
These limitations would all require adding code to the new version to
handle the old data types and their behaviour and to convert them to
the new datatypes when a tuple is rewritten. In some cases this is
really not easy at all.
--
greg