From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>,  pgsql-hackers@postgresql.org
Subject: Re: MultiXactId error after upgrade to 9.3.4
In-Reply-To: <20160615233427.GA18976@alvherre.pgsql> (Alvaro Herrera's message
	of "Wed, 15 Jun 2016 19:34:27 -0400")
Message-ID: <878ty5seyr.fsf@news-spur.riddles.org.uk>
References: <20160615233427.GA18976@alvherre.pgsql>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix)
Date: Thu, 16 Jun 2016 09:50:46 +0100
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

>>>>> "Alvaro" == Alvaro Herrera <alvherre@2ndquadrant.com> writes:

 Alvaro> I think that was a good choice in general so that
 Alvaro> possibly-data-eating bugs could be reported, but there's a
 Alvaro> problem in the specific case of tuples carried over by
 Alvaro> pg_upgrade whose Multixact is "further in the future" compared
 Alvaro> to the nextMultiXactId counter.  I think it's pretty clear that
 Alvaro> we should let that error be downgraded to DEBUG too, like the
 Alvaro> other checks.

But that leaves an obvious third issue: it's all very well to ignore the
pre-upgrade (pre-9.3) mxid if it's older than the cutoff or it's in the
future, but what if it's actually inside the currently valid range?
Looking it up as though it were a valid mxid in that case seems to be
completely wrong and could introduce more subtle errors.

(It can, AFAICT, be inside the currently valid range due to wraparound,
i.e. without there being a valid pg_multixact entry for it, because
AFAICT in 9.2, once the mxid is hinted dead it is never again either
looked up or cleared, so it can sit in the tuple xmax forever, even
through multiple wraparounds.)

Why is the correct rule not "check for and ignore pre-upgrade mxids
before even trying to fetch members"?

-- 
Andrew (irc:RhodiumToad)


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