Re: Proposal: In-Place upgrade concept

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: In-Place upgrade concept
Date: 2007-07-03 18:14:27
Message-ID: 468A9203.1000705@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout wrote:
> On Tue, Jul 03, 2007 at 07:13:29PM +0200, Zdenek Kotala wrote:
>> pg_migrator is separate tool which requires old postgres version and I
>> would like to have solution in postgres binary without old version
>> presence. Very often new postgres version is store in same location
>> (e.g. /usr/bin) and normal users could have a problem.
>
> Possibly. But you have to demonstrate it actually works and it's best
> to do that with a seperate process. Or fix pg_migrator to not require
> the old version, either way will do.

Pg_migrator use pg_dump for dump catalog and main concept is based on
presence of old postgres version. I think Fix it means rewrite it.

>>> I think insisting on a downgrade option is an absolutely certain way
>>> of guaranteeing that the project will fail.
>> How I mentioned before. This is nice to have requirement. I would like
>> to have in the mind and when it starts complexity explosion we can
>> remove it from the requirement list.
>
> It seems to me that if every step of the process is WAL logged, then
> downgrading is simply a matter of restoring and using PITR. Downgrades
> are hard work, primarily because in the long run it's going to be
> totally untested code because hardly anyone is going to need it.

It is not downgrade. It is about keep old structure until user says
convert to the new data structure.

>> Yes, there is way to keep old and new implementation of index and each
>> will have different oid. Primary key for pg_am table will be
>> name+pg_version - It is similar to UDT solution. CREATE INDEX as a
>> REINDEX will use actual implementation.
>
> Bad idea. Indexes are already complicated peices of code, there's no
> guarentee the old code will even work with the new version. Seems like
> too much work considering REINDEX will simply fix the problem outright.

I do not expect that old code will work with new index structure. I want
to keep both implementation and old index will be processed by old code
and new one will be processed by new implementation. Each will have
different OID and pg_class.relam will point to correct implementation.
These obsolete index method could be located in separate compat lib.

Zdenek

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-07-03 18:27:07 Re: Proposal: In-Place upgrade concept
Previous Message Tom Lane 2007-07-03 18:09:22 Re: Proposal: In-Place upgrade concept