Re: pg_upgrade (was: 8.2 features status)

* Jim C. Nasby (jnasby(at)pervasive(dot)com) wrote:
> On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote:
> > * Jim C. Nasby (jnasby(at)pervasive(dot)com) wrote:
> > > How would such a thing handle changes to page formats?
> >
> > Couldn't this be done by converting a table/partial-table at a time?
> > It wouldn't be something which could run while the system is live, but
> > it'd probably take less time than dump/restore and wouldn't require
> > double the disk space of the whole database... no?
>
> True, but if you're going to go about creating code that can deal with 2
> different versions of on-disk data, why not go one better: put that code
> into the database itself, so that pages are converted on-the-fly as
> they're dirtied. That way you have *no* downtime (or almost no, anyway).

Certainly a good idea but I'm really not sure that: a) we'd want the
core server to have essentially cruft code and b) that it'd be anywhere
near simple to make this actually work in the core system.

Supporting two versions of the page format when the only goal is
changing the formatting is quite a different thing than fully supporting
two on-disk formats throughout the backend. Additionally, if you have
something to convert the database wholesale then that really just needs
to support 2 versions at a time, if it's piecemeal then you could end up
in a situation where you have to support 3, 4, 5, however many prior
page formats existed. If not then you have to have a way to force all
the pages to be upgraded and you're unlikely to be able to do a whole
lot more with the system while that's happening, thus adding alot of
extra complication just to end up having everyone follow the
'pg_upgrade'-style path anyway...

In the end though, I think once it's been done in pg_upgrade this could
be revisited and considered and if enough people are interested in doing
it they could probably reuse some of hte pg_upgrade code to make it
happen.

Thanks,

Stephen