Re: Proposal: In-Place upgrade concept

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: In-Place upgrade concept
Date: 2007-07-03 10:53:53
Message-ID: 468A2AC1.8040709@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-07-03 11:05:07 Re: Proposal: In-Place upgrade concept
Previous Message Gregory Stark 2007-07-03 10:50:02 Re: Proposal: In-Place upgrade concept