Date: Mon, 31 Mar 2014 10:34:24 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org
Subject: Re: MultiXactId error after upgrade to 9.3.4
Message-ID: <20140331143424.GR4582@tamriel.snowman.net>
References: <20140330040029.GY4582@tamriel.snowman.net>
 <20140330141135.GA4582@tamriel.snowman.net>
 <20140330185349.GD4582@tamriel.snowman.net>
 <20140331115452.GT9567@eldon.alvh.no-ip.org>
 <20140331115713.GA18358@alap3.anarazel.de>
 <20140331140245.GX9567@eldon.alvh.no-ip.org>
 <20140331142520.GY9567@eldon.alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="sbrHKXJRpOukoEIg"
Content-Disposition: inline
In-Reply-To: <20140331142520.GY9567@eldon.alvh.no-ip.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > I think this rule is wrong.  I think the rule ought to be something like
> > "if the XMAX_INVALID bit is set, then reset whatever is there if there
> > is something; if the bit is not set, proceed as today".  Otherwise we
> > risk reading garbage, which is what is happening in this case.
>=20
> Andres asks on IM: How come there is garbage there in the first place?
> I have to admit I have no idea.

I haven't got any great explanation for that either.  I continue to feel
that it's much more likely that it's an xid than a multixid.  Is it
possible that it was stamped with a real xmax through some code path
which ignored the IS_MULTI flag?  This could have been from as far back
as 9.0-era.  On this over-7TB database, only this one tuple had the
issue.  I have another set of databases which add up to ~20TB that I'm
currently testing an upgrade from 9.2 to 9.3 on and will certainly let
everyone know if I run into a similar situation there.

On our smallest DB (which we upgraded first) which is much more OLTP
instead of OLAP, we didn't run into this.

This is all on physical gear and we've seen no indications that there
has been any corruption.  Hard to rule it out completely, but it seems
pretty unlikely.

	Thanks,

		Stephen

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

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

iQIcBAEBAgAGBQJTOXzvAAoJEO1sijiDR2RVyucQAK3seo9Z/iMpFk5N7WQoeAfS
Q5wwz7s6kqQ291QE4+TSotDtO9we3akXbNsYJktMHtW1ZHDoFrKwgVWzLAzMc2Ru
4jEk8Em6/3Yjh50hDLVjlOEUaz80O/QypsNkDv55NbdTmuQNkFoVYRJilmEcDJXU
n2lznqE2VWrvR2in4Jlrien1PblG/gcH9lkqL5E+pGJ4/RDL8Kmg/GOczpkymwBQ
XsEvIUSOnqfrvXc68E+g+hVqlU2MueIunEXTkDOtel/GGnO5ihmxwyS88RZY5mOk
3eNA6knY62Wk3mT5VaX93X85MYzHgnNcxBrF+7uDLlvqLj3E9WmEUn8/pRwcE5Vo
FeocbukrouoU+iNttnFi18oUKqY2b2BDQN21GLPPIYmfCEYzxu4v8z/gpEUXSzmL
NEYM3ONb8EMmO7YdHzkT/UL2R09ETULMsAGCxBwqVs3YDqald0THolkMG+fXxbYB
Utdg0g90rfGHwjBMElcdmMZIB8zUOj+TLuQNor8YBRhqxeyMlLpB9oNNzQsHbpAM
Q5It0SqdvHe8J4VS+Byrupa+6GlfcgxC8rJ/MtEj2QETbgL9jlniCnaEvLWi6Ntb
J8qDwNWflmPpOzPpbguDcEiDPQ1PzTbkxXRlS/dgHL2sW4ziFjuIiTI4Cj2FqWV/
AqdfcA/e1aKGCVUCAaP0
=ptfh
-----END PGP SIGNATURE-----

--sbrHKXJRpOukoEIg--