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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to