From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MultiXactId error after upgrade to 9.3.4 |
Date: | 2014-03-31 13:42:25 |
Message-ID: | 20140331134225.GQ4582@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2014-03-31 09:09:08 -0400, Stephen Frost wrote:
> > * Alvaro Herrera (alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2014-03-31 13:43:32 | Re: B-Tree support function number 3 (strxfrm() optimization) |
Previous Message | Yugo Nagata | 2014-03-31 13:38:22 | Re: Fwd: Proposal: variant of regclass |