From: Bruce Momjian on 16 Feb 2010 09:04 Greg Smith wrote: > If you think through the implications of that far enough, eventually you > start to realize that you really can't even add a feature that requires > an in-place upgrade hack to fix without first having the code that > performs said hack done. Otherwise you're never completely sure that > you put the right catalog pieces and related support code into the > version you want to upgrade from. This is why it's not unheard of for > commercial database products to require a working in-place upgrade code > *before* the feature change gets committed. > > In this case, we get a lucky break in that it's easy to leave support > for old path in there and punt the problem for now. I hope that we all > learn something useful about this class of issue during this opportunity > to get away with that with little downside. Yea, the crux of the matter is that we are getting away easy with 9.0 in only having to keep around some MOVE_* code in tqual.c. This is just the start of the pain we will have to bear for inplace upgrades. :-( The MOVE_* bits go away after a while by vacuum and there is an easy solution for 9.1 --- vacuum everything in 9.0. Where things really get hard is when we have to support two page formats or two data formats in the same database. You might think we will never get there, but there have been such changes in the past, and I suspect that we will have them in the future, maybe not in 9.1, but perhaps 9.3. Ultimately we are going to have to decide how to resolve the burden of code used just for binary upgrades, and as Tom pointed out, it is very hard to remove the old data format in the old database because new sessions could be creating it while it is being removed. It seems that only the next major version can clean out the old format, meaning you have to keep support for the old format around for a full major release, add code to remove it in that major release too, then remove all of the code in the _next_ major release. This is frankly a complexity we have never had to deal with before, and we don't even have the infrastructure to track that all of the old format is gone. So, in summary, MOVE_* problems look minor compared to the complexities ahead. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: OpenVMS? Next: bug? autovacuum is not launched even ifautovacuum_freeze_max_age is reached |