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