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

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(at)2ndQuadrant(dot)com www.2ndQuadrant.com