Re: MultiXactId error after upgrade to 9.3.4

>>>>> "Alvaro" == Alvaro Herrera <alvherre(at)2ndquadrant(dot)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)