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


--6gQwMJXxXgY8ZpDE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* Stephen Frost (sfrost@snowman.net) wrote:
> 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..).

Further review leads me to notice that both HEAP_XMAX_IS_MULTI and
HEAP_XMAX_INVALID are set:

t_infomask  | 6528

6528 decimal -> 0x1980

0001 1001 1000 0000

Which gives us:

0000 0000 1000 0000 - HEAP_XMAX_LOCK_ONLY
0000 0001 0000 0000 - HEAP_XMIN_COMMITTED
0000 1000 0000 0000 - HEAP_XMAX_INVALID
0001 0000 0000 0000 - HEAP_XMAX_IS_MULTI

Which shows that both HEAP_XMAX_INVALID and HEAP_XMAX_IS_MULTI are set.
Of some interest is that HEAP_XMAX_LOCK_ONLY is also set..

> 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?

The 'improve concurrency of FK locking' patch included a change to
UpdateXmaxHintBits():

- * [...] Hence callers should look
- * only at XMAX_INVALID.

...

+ * Hence callers should look only at XMAX_INVALID.
+ *
+ * Note this is not allowed for tuples whose xmax is a multixact.

[...]

+   Assert(!(tuple->t_infomask & HEAP_XMAX_IS_MULTI));

What isn't clear to me is if this restriction was supposed to always be
there and something pre-9.3 screwed this up, or if this is a *new*
restriction on what's allowed, in which case it's an on-disk format
change that needs to be accounted for.

One other thing to mention is that this system was originally a 9.0
system and the last update to this tuple that we believe happened was
when it was on 9.0, prior to the 9.2 upgrade (which happened about a
year ago), so it's possible the issue is from the 9.0 era.

	Thanks,

		Stephen

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

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

iQIcBAEBAgAGBQJTOGg8AAoJEO1sijiDR2RV5xcQAMN8IeeEKhexTdGYhGGxZ4ZT
OdCOZiLKJBuozOTqZKfAjK5bYQahKsRm4sRAgGLEubUAXslPrBqLnJ4KMZeUmp5a
WlLMXqyuYATY2XBco+5h9PUVdiMvUsyOLmIlPWmdlLu/SnesOJCHOuQa4Jrme12O
3oA+lmLY03W6sXg8t7c9AaKDu/krim0VgVntESKExnaIQ7ClQm6T0kixEZoFq3tS
iCUolnKr/hnM/ljAYFn9DxYaBAkUWn5UWzCQHzoL2xSzvhCKNVa8jD582xPoOgYy
w1F29jf7Amm7pA5ZRcYt8jvOIpHxVb6boVwF5WBmeuKH9o1worB04mO5Wyt/c7XK
xYfa8lc3MQ8Ox/NNEjfYKgvMbDL8hSomcbdsdJGUgdGcLtuf0n+tJK6DopFbaSpc
iTXNO7egmT89AWaePLtSIv+cXap2A9WdIC7Wy92AaQrKcNOlhSCCahrexqTxq4OU
3MGYFLBPaE4lZPAB8wtDeJiuKyIJNKXCIWf86Ts/yzoootImfJ2ZYmAZfFbjRD4K
2A6nRTrFRTvHrU6/+pNUb4sg48Q1zLTla7CKhwId9oDCNBMzhQaUG3tKhE0uRx73
9cxZ5P445vUE6CrDRtAJYIpXOSsLlrgBv5kTHdozpx00T6waKnV//Ict+EMwgyBT
wc+lgkiV39mP/EWbk3Bn
=xQEO
-----END PGP SIGNATURE-----

--6gQwMJXxXgY8ZpDE--