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

From Zdenek Kotala
Subject Re: Proposal: In-Place upgrade concept
Date
Msg-id 468A9203.1000705@sun.com
Whole thread Raw
In response to Re: Proposal: In-Place upgrade concept  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Proposal: In-Place upgrade concept  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: In-Place upgrade concept
Next
From: Tom Lane
Date:
Subject: Re: Proposal: In-Place upgrade concept