Re: MultiXactId error after upgrade to 9.3.4
От | Andres Freund |
---|---|
Тема | Re: MultiXactId error after upgrade to 9.3.4 |
Дата | |
Msg-id | 20140331131807.GC18358@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: MultiXactId error after upgrade to 9.3.4 (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: MultiXactId error after upgrade to 9.3.4
|
Список | pgsql-hackers |
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? > > 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
В списке pgsql-hackers по дате отправления: