Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +