On 2013-10-21 16:15:58 +0200, Andres Freund wrote:
> On 2013-10-21 09:32:12 -0400, Robert Haas wrote:
> > On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > > I know of the following solutions:
> > > 1) Don't allow VACUUM FULL on catalog tables if wal_level = logical.
> > > 2) Make VACUUM FULL prevent DDL and then wait till all changestreams
> > > have decoded up to the current point.
> > > 3) don't delete the old relfilenode for VACUUM/CLUSTERs of system tables
> > > if there are life decoding slots around, instead delegate that
> > > responsibility to the slot management.
> > > 4) Store both (cmin, cmax) for catalog tuples.
> > >
> > > I bascially think only 1) and 4) are realistic. And 1) sucks.
> > >
> > > I've developed a prototype for 4) and except currently being incredibly
> > > ugly, it seems to be the most promising approach by far. My trick to
> > > store both cmin and cmax is to store cmax in t_hoff managed space when
> > > wal_level = logical.
> >
> > 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.
Greetings,
Andres Freund
PS: The patch is ontop of a new git push, but for review that shouldn't
matter.
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services