Re: MultiXactId error after upgrade to 9.3.4

* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2014-03-31 09:09:08 -0400, Stephen Frost wrote:
> > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > > I guess I wasn't expecting that too-old values would last longer than a
> > > full wraparound cycle.  Maybe the right fix is just to have the second
> > > check also conditional on allow_old.
> >
> > I don't believe this was a wraparound case.
>
> Could you show pg_controldata from the old cluster?

Per the original email-
 The *OLD* (9.2.6) control data had:
 pg_control version number:            922 Catalog version number:               201204301
 Latest checkpoint's NextXID:          0/40195831 Latest checkpoint's NextOID:          53757891
 Latest checkpoint's NextMultiXactId:  1601462 Latest checkpoint's NextMultiOffset:  4503112
 Latest checkpoint's oldestXID:        654 Latest checkpoint's oldestXID's DB:   12870 Latest checkpoint's
oldestActiveXID: 0
 
 (It doesn't report the oldestMulti info under 9.2.6).

Was there something else you were looking for?

> > I don't think the xmax value is a multixact at all- I think it's
> > actually a regular xid, but everyone is expected to ignore it because
> > XMAX_IS_INVALID, yet somehow the MULTIXACT bit was also set and the new
> > code expects to be able to look at the xmax field even though it's
> > marked as invalid..
>
> XMAX_IS_INVALID was never allowed to be ignored for vacuum AFAICS. So I
> don't think this is a valid explanation.

The old 9.2 cluster certainly had no issue w/ vacuum'ing this
table/tuple.  Unfortunately, I can't have the 9.2 debug packages
installed concurrently w/ the 9.3 debug packages, so it's a bit awkward
to go back and forth between the two.  Anything else of interest while I
have the 9.3 instance running under gdb?  Sent the requested backtrace
in another email.
Thanks,
    Stephen