Re: Proposal: In-Place upgrade concept
От | Zdenek Kotala |
---|---|
Тема | Re: Proposal: In-Place upgrade concept |
Дата | |
Msg-id | 468A9203.1000705@sun.com обсуждение исходный текст |
Ответ на | Re: Proposal: In-Place upgrade concept (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Proposal: In-Place upgrade concept
|
Список | 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 по дате отправления: