Re: Proposal: In-Place upgrade concept - Mailing list pgsql-hackers

Heikki Linnakangas wrote:
> 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.

This should be problem if you want to upgrade operation system together 
with DB and new operation system does not have this version. This 
requirement is based on operation system vendor and also on my 
experience with Oracle upgrade on tru64 cluster when two version of 
installed Oracle does not works good - ok postgresql is better in this 
way :-).


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

I don't think that it increase complexity much. You will have conversion 
function to convert page/data from version x->x+1 and the same way could  be use to convert data back. It need more
investigation,but I'm not 
 
afraid about complexity (meanwhile :-).

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

One kind of problem is user defined type/function and extension. You can 
test a lot of things on test machines, but some problem could occur on 
big tables/storage. No many postgresql users have multiterrabyte disk 
array for testing.

Second kind of problem is operation system upgrade. If you upgrade OS 
and postgresql together and something fails (not only new version of 
postgresql, but many other things) then admin want to revert back to the 
old  OS version with old postgres version. In Solaris it is called Live 
Upgrade feature.

This feature enable possibility to do it easily. However, backup/restore 
is possible solution - unfortunately not much comfortable. I think it is 
nice to have requirement and if it will be possible we can do that, if 
it will bring a lot of complication, we can remove it.

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

For example Oracle 10 implemented some new incremental backup feature. 
But you can use it only when you have converted database to correct 
format. I'm not oracle and I'm not able to predict which new feature in 
postgresql will require all updated pages for example. I don't expect 
that database upgrading mode will affect a lot of new features but we 
must have it in the mind.

Zdenek