Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
От | Greg Smith |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while |
Дата | |
Msg-id | 4B76640F.1080404@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL
(which was known for a little while
(Robert Haas <robertmhaas@gmail.com>)
Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while (Bruce Momjian <bruce@momjian.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: