Date: Wed, 15 Jun 2016 19:36:38 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: sean.hope@eroad.com, pgsql-bugs@postgresql.org
Subject: Re: BUG #14195: "MultiXactId XXXXXX has not been created yet
 -- apparent wraparound" after upgrade from 9.2
Message-ID: <20160615233638.GA41007@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87inxarrd6.fsf@news-spur.riddles.org.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs