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

Robert Haas wrote:
> Recording some bookkeeping information in pg_class so that pg_migrator can tell what's going on
> at a glance seems like the right approach, but I'm fuzzy on the details.
>   

November of 2008 was a pretty good month for me, so I enjoyed this 
flashback to it.  That's when the path for how to handle space 
reservation wandered to this same place and then died there:  how to 
know for sure what information to put into the catalog for the upgrade 
utility, before the upgrade utility exists.  Message from Bruce at 
http://archives.postgresql.org/message-id/200901300457.n0U4v1707979@momjian.us 
and my follow-up summarized/linked to the highlights of the earlier 
discussion on that one.

This time around, the way the upgrade is being staged allows a possible 
path through this dependency chain, as noted by Tom:

> It would probably be useful to have a utility that runs *in 9.0* and
> gets rid of MOVED bits, so that we could drop support for them in 9.1.
> But it's not happening for 9.0.

As long as this one gets deprecated nicely here--so the server still 
knows how to deal with the ugly parts, but will not introduce any more 
of them--this should make for a good test case to gain experience with 
handling this whole class of problem.  If the above exercise finishes 
with a clear "had we just recorded <x> in the catalog before 9.0 came 
out we could have done this more easily", I think it would be much more 
likely that a future "we should record <y> in the catalog to improve the 
odds of adding this feature in a way that can upgrade to it in-place" 
decision might get made correctly in advance of the upgrade utility 
actually existing.  Right now, just like the 8.4 case, it seems quite 
possible no one will develop a plan in time they can prove will work 
well enough to justify adding speculative catalog support for it.  Much 
easier to figure that out in retrospect though, after the matching 
utility that uses the data exists.

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.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com