Re: In-place upgrade: catalog side

Greg Smith napsal(a):
>
> The main thing you'll find there is a ksh script that handles most of
> the upgrade, presuming there's no page format changes. It looks like it
> was originally aimed at 8.1->8.2 upgrades (easy as long as you don't use
> INET/CIDR in your database) and still has some hard-coded stuff from
> that in there to clean up.

Yes, It is correct. It is only for 8.1->8.2. It works fine for 8.3->8.4 too, but
I'm working on cleanup and fixing bugs. I hope that I will send updated version
to community today.

<snip>

> I'd like to start doing something constructive to help move this part
> forward, so here's an initial set of questions I've got for mapping that
> work out:
>
> -A ksh script for something this critical is a non-starter on Windows in
> particular, so a good plan would be to use Zdenek's script as a
> malleable prototype, confirm it works, then update pg_migrator with
> anything it's missing, right?

It is more workaround or temporary solution. This approach is easy but it has
lot of limitation. Problem with toast tables is one, but biggest problem is with
dropped columns. And maybe there will be more issues. Problem with dump is that
you lost a internal data.

I personally prefer to have special mode (like boostrap) which converts data
from old catalog to new format.

I think pg_upgrade.sh is good starter, before we will implement direct catalog
upgrade.

> -Are there already any specific tasks done by Zdenek's script that are
> already known to be unique to only its implementation? Eventually I
> expect I'll figure that out for sure myself just by comparing the code,
> was curious what the already known divergences were.

If you compare with pg_migrator, there is better handling of locale and I think
vacuum freeze is used correctly. Also shuffling with tablespaces is little bit
different (it should avoid to move data outside of mountpoint). But in principal
the idea is same.

> -There are 10 TODO items listed for the pg_migrator project, most or all
> of which look like should be squashed before this is really complete.
> Any chance somebody (Korry?) has an improved version of this floating
> around beyond what's in the pgfoundry CVS already?

As I mentioned before pg_migrator and pg_upgrade.sh is not good way. It is
workaround. It does not make sense to continue in this way.

Zdenek