* Andres Freund (and...@2ndquadrant.com) wrote: > On 2014-03-31 09:09:08 -0400, Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@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
Description: Digital signature