Re: Proposal: In-Place upgrade concept

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
asin 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
thenew data file format and the old data file format. Features of a new version might not be available. PostgreSQL have
tobe able to recover and continue in the upgrade mode in case of a power/system failure. Fallback to the previous
versionis 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