Date: Sun, 30 Mar 2014 10:11:35 -0400
From: Stephen Frost <sfrost@snowman.net>
To: pgsql-hackers@postgresql.org
Subject: Re: MultiXactId error after upgrade to 9.3.4
Message-ID: <20140330141135.GA4582@tamriel.snowman.net>
References: <20140330040029.GY4582@tamriel.snowman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="P5jslYRVNanHST2M"
Content-Disposition: inline
In-Reply-To: <20140330040029.GY4582@tamriel.snowman.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--P5jslYRVNanHST2M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

All,

* Stephen Frost (sfrost@snowman.net) wrote:
>   Looks like we might not be entirely out of the woods yet regarding
>   MultiXactId's.  After doing an upgrade from 9.2.6 to 9.3.4, we saw the
>   following:
>=20
>   ERROR:  MultiXactId 6849409 has not been created yet -- apparent wrapar=
ound

While trying to get the production system back in order, I was able to
simply do:

select * from table for update;

Which happily updated the xmax for all of the rows- evidently without
any care that the MultiXactId in one of the tuples was considered
invalid (by at least some parts of the code).

I have the pre-upgrade database and can upgrade/rollback/etc that pretty
easily.  Note that the table contents weren't changed during the
upgrade, of course, and so the 9.2.6 instance has HEAP_XMAX_IS_MULTI set
while t_xmax is 6849409 for the tuple in question- even though
pg_controldata reports NextMultiXactId as 1601462 (and it seems very
unlikely that there's been a wraparound on that in this database..).

Perhaps something screwed up xmax/HEAP_XMAX_IS_MULTI under 9.2 and the
9.3 instance now detects that something is wrong?  Or is this a case
which was previously allowed and it's just in 9.3 that we don't like it?
Hard for me to see why that would be the case, but this really feels
like HEAP_XMAX_IS_MULTI was incorrectly set on the old cluster and the
xmax in the table was actually a regular xid..  That would have come
=66rom 9.2 though.

	Thanks,

		Stephen

--P5jslYRVNanHST2M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJTOCYWAAoJEO1sijiDR2RV+VsP/RNiMR5VEKyieQCYt0wxI3H/
4VkYbM+z9xoIDHx0Ngr/fJiVVU8YWGk9HHijjI3iMOLf09XnO39Zuma98nu2hh46
0Yupftv6SQE24cgmQj7BxG+JZIzr2AMFXoA7Rn6GHyNtmq/JGLy65eed47oAdn9m
I2hyFtN+5n/BxAIWeCxKVoNUFcQH+MElpQiFjhkSL6QtbNUll7Zd74uWi/suTg17
qIg1DFBfCfFcz43zl4HZYogcYlhmTavkiFM4r/+GNJKQdhXfTePIOiNbnY6HuP1d
GfJuLe4G2r9lWNUl1sGYyXgIld5rCmQNPXayKMM5j42AMkVeJucIT3DRQ9rp8AGE
E2npuryre9wfRJkvfPVqCO8++jk0osXcxvHdiUk7LkNFH2snzRTxu2HG46WpZyNR
vYkTUf5x96oS99tshNicB576aopA2WQwVvzH+Wna6VRXhFID+Ac69q4GZe0oKWJm
oukA9/2V7+FY7+gPAoBmDfmVJI50W0Uqn9cMMjnFh2GJtYIHfWxze9RBVD/CQLmQ
x3BCRXZBM+RRmfwHY1O5f8xbpr8w+0oz98fpRH+kEooWC2B5F463JcN3+46uuZ1l
PK8KFhPEe4OV9rq6OUrn4SIAM7r9NGgw2IWJuxaDmOqoBmCKYXjNZGPjDTEuPdbR
s9c0TYtPH+8Myab0LCP5
=Dk25
-----END PGP SIGNATURE-----

--P5jslYRVNanHST2M--