Re: Upgrading rant.

----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Sent: January 03, 2003 6:31 PM

> Tom Lane wrote:
> > The system tables are not the problem. pg_upgrade has shown how we
> > can have cross-version upgrades no matter how much the system catalogs
> > change (a good thing too, because we cannot freeze the system catalog
> > layout without bringing development to a standstill). A schema-only
> > dump and restore is cheap enough that there's no real reason to look
> > for any other solution.
> >
> > Changes in the on-disk representation of user tables would be harder to
> > deal with, but they are also much rarer (AFAIR we've only done that
> > twice: WAL required additions to page and tuple headers, and then there
> > were Manfred's space-saving changes in 7.3). And as of 7.3 there is a
> > version field in page headers, which would in theory allow for a
> > page-at-a-time update process to work.
> >
> > There isn't any fundamental reason why we cannot have a pg_upgrade
> > utility; claiming that there is something wrong with how we handle
> > catalog changes misses the point. The point is that *someone would
> > have to do the work*. Unless someone wants to step up and volunteer,
> > there's little value in discussing it.
>
> pg_upgrade does work, assuming there are no changes to the index or heap
> file formats. (However, I now need to update it for schemas.) However,
> the last time I worked on it for 7.2, no one was really interested in
> testing it, so it never got done. In fact, there was a bug in the
> handling of clog or wal files, but I didn't find out about it until long
> after 7.2 because no one was using it.

I guess the main point here was to have co-existing versions of data
in the /data dierectory and the sever be able to the talk to all of them,
with an option to upgrade the data to the most recent format at some point.

If it's done that way, there won't be much of a pain if at all to upgrade
the server only and benifit from the general bug-fixes and general new features.
The specific features that require more recent data models, will have to
be tracked down, and dealt with if attempted for the older data model.

The other main point was to find smb to do the dirty job of implementing,
maintaining, and tracking down format changes of that concurrent data storage
"model".

pg_upgrade would be the tool to envetually upgrade the data to the
recent model in that case.

> Is pg_upgrade too hard to run? Is no one really interested in it?

Would still be nice to have some GUI to it in Java/Web/*Admin/TclTk etc.
It pg_upgrade documented anywhere besided man pages and the script itself?

-s