On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith <g...@2ndquadrant.com> wrote: > 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.n0u4v1707...@momjian.us > and my follow-up summarized/linked to the highlights of the earlier > discussion on that one.
Sure. I think there's an a critical difference between the two discussions: the framework I'm proposing is general and applicable to almost any upgrade situation that changes the ODF in any way, and provides a general way of eventually desupporting ODFs we no longer want. The previous discussion was about a space reservation system which couldn't be made to work for a variety of reasons, including uncertainty about what the future needs might be, and lack of any sort of bookkeeping system (such as the one I'm proposing here) for tracking the current state of the system. > 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. Agreed. > 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. Yep. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
