From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: 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
In-Reply-To: <20160615203829.5798.4594@wrigleys.postgresql.org> (sean hope's
	message of "Wed, 15 Jun 2016 20:38:29 +0000")
Message-ID: <87inxarrd6.fsf@news-spur.riddles.org.uk>
References: <20160615203829.5798.4594@wrigleys.postgresql.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix)
Date: Thu, 16 Jun 2016 00:17:04 +0100
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

>>>>> "sean" == sean hope <sean.hope@eroad.com> writes:

 sean> The following bug has been logged on the website:
 sean> Bug reference:      14195
 sean> Logged by:          Sean Hope
 sean> Email address:      sean.hope@eroad.com
 sean> PostgreSQL version: 9.4.7
 sean> Operating system:   Ubuntu 12.04 LTS
 sean> Description:        

 sean> Hi,

 sean> We're having issues with 'MultiXactId xxxxxxxxx has not been
 sean> created yet -- apparent wraparound' log messages upon table
 sean> vacuums. The vacuums are cancelled by the system after this
 sean> message is issued.

 sean> These messages have only been seen since upgrading from 9.2.x to
 sean> 9.4.7 via pg_upgrade about a month ago. This is a large / high
 sean> transaction rate (1120 tps) database. We are unable to vacuum the
 sean> affected tables (5 of them) currently due to this issue.

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.