Re: logical changeset generation v6.2

On 2013-10-21 14:22:17 -0400, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 1:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> > In my opinion, (4) is too ugly to consider. I think that if we start
> >> > playing games like this, we're opening up the doors to lots of subtle
> >> > bugs and future architectural pain that will be with us for many, many
> >> > years to come. I believe we will bitterly regret any foray into this
> >> > area.
> >>
> >> Hm. After looking at the required code - which you obviously cannot have
> >> yet - it's not actually too bad. Will post a patch implementing it later.
> >>
> >> I don't really buy the architectural argument since originally cmin/cmax
> >> *were* both stored. It's not something we're just inventing now. We just
> >> optimized that away but now have discovered that's not always a good
> >> idea and thus don't always use the optimization.
> >>
> >> The actual decoding code shrinks by about 200 lines using this logic
> >> which is a hint that it's not a bad idea.
> >
> > So, here's a preliminary patch to see how this would look. It'd be great
> > of you comment if you still think it's a completel no-go.
> >
> > If it were for real, it'd need to be split and some minor things would
> > need to get adjusted, but I think it's easier to review it seing both
> > sides at once.
>
> I think it's a complete no-go. Consider, e.g., the comment for
> MaxTupleAttributeNumber, which you've blithely falsified. Even if you
> update the comment and the value, I'm not inspired by the idea of
> subtracting 32 from that number; even if it weren't already too small,
> it would break pg_upgrade for any users who are on the edge.

Well, we only need to support it for (user_)catalog tables. So
pg_upgrade isn't a problem. And I don't really see a problem restricting
the number of columns for such tables.

> Things
> aren't looking too good for anything that uses HeapTupleFields,
> either; consider rewrite_heap_tuple().

Well, that currently works, by copying cmax. Since rewriting triggered
the change, I am pretty sure I've actually tested & hit that path...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services