On Wed, Dec 21, 2011 at 11:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It seems like you've forgotten all of the previous discussion of how
> we'd manage a page format version change.
Maybe I've had too much caffeine. It's certainly late here.
> Having two different page formats running around in the system at the
> same time is far from free; in the worst case it means that every single
> piece of code that touches pages has to know about and be prepared to
> cope with both versions. That's a rather daunting prospect, from a
> coding perspective and even more from a testing perspective. Maybe
> the issues can be kept localized, but I've seen no analysis done of
> what the impact would be or how we could minimize it. I do know that
> we considered the idea and mostly rejected it a year or two back.
I'm looking at that now.
My feeling is it probably depends upon how different the formats are,
so given we are discussing a 4 byte addition to the header, it might
be doable.
I'm investing some time on the required analysis.
> A "utility to bump the page version" is equally a whole lot easier said
> than done, given that the new version has more overhead space and thus
> less payload space than the old. What does it do when the old page is
> too full to be converted? "Move some data somewhere else" might be
> workable for heap pages, but I'm less sanguine about rearranging indexes
> like that. At the very least it would imply that the utility has full
> knowledge about every index type in the system.
I agree, rewriting every page is completely out and I never even considered it.
>> I'm now personally game on to make something work here for 9.2.
>
> If we're going to freeze 9.2 in the spring, I think it's a bit late
> for this sort of work to be just starting.
I agree with that. If this goes adrift it will have to be killed for 9.2.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
