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
possible.
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
