From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | sean(dot)hope(at)eroad(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14195: "MultiXactId XXXXXX has not been created yet -- apparent wraparound" after upgrade from 9.2 |
Date: | 2016-06-15 23:36:38 |
Message-ID: | 20160615233638.GA41007@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth wrote:
> This one came up on the IRC channel and I did some analysis there.
>
> What it seems to boil down to is that, faced with a tuple with a
> pre-upgrade mxid, we get this call path:
>
> vacuum calls heap_prepare_freeze_tuple
>
> heap_prepare_freeze_tuple calls FreezeMultiXactId
> (because HEAP_XMAX_IS_MULTI)
>
> FreezeMultiXactId checks if the mxid is older than the cutoff, but
> because this is a pre-upgrade mxid it can be literally anything, and in
> this case it's in the future not the past, so that check is skipped
>
> FreezeMultiXactId calls GetMultiXactIdMembers with allow_old=true
>
> GetMultiXactIdMembers checks for wraparound, but while it downgrades the
> error to DEBUG1 if allow_old is true and the mxid is in the past, it
> unconditionally errors if the mxid is in the future.
I was in the middle of writing up this in another thread, and your
analysis in spot on.
https://www.postgresql.org/message-id/20160615233427.GA18976@alvherre.pgsql
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-16 05:45:04 | Re: Segmentation fault with postgres -C external_pid_file |
Previous Message | Andrew Gierth | 2016-06-15 23:17:04 | Re: BUG #14195: "MultiXactId XXXXXX has not been created yet -- apparent wraparound" after upgrade from 9.2 |