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? > > Anyway, it's not clear to me why this database has a multixact value of > > 6 million when the next multixact value is barely above one million. > > Stephen said a wraparound here is not likely. > > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers