Zdenek Kotala wrote:
Project Goals
3) Do not require an old version of PostgreSQL to be installed.

Why not? Having two versions installed at the same time doesn't seem like a problem to me. You can remove the old version as soon as the upgrade is done.

4) Allow a fallback to original PostgreSQL version if something would go wrong.
compatibility mode (compat) - a new version is running on the old data files. 
It is possible to read and write data as in a previous version. Features of a 
new version might not be available. Fallback to the previous version is 

That's madness. Why would you want to do that? The complexity it adds is just mind-boggling.

You still wouldn't be able to downgrade after you switch from compatibility mode, and it seems likely that any problems, whatever they might be, would not appear until you switch. That means you'll need to be prepared to downgrade using a backup anyway, so the compatibility mode doesn't buy you much.

upgrade mode - a conversion of data files is running in the background. 
PostgreSQL have to be able to work with both the new data file format and the 
old data file format. Features of a new version might not be available. 
PostgreSQL have to be able to recover and continue in the upgrade mode in case 
of a power/system failure. Fallback to the previous version is not possible.

That's feasible, though I don't see why new features wouldn't be available.

As before, upgrade can be done, it's just a matter of someone scratching the itch. pg_migrator can handle the catalog changes. Doing the page conversion from 8.2 -> 8.3 is possible, and it could be done on-the-fly inside PostgreSQL the first time a page is read in.

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to