>>>>> "Alvaro" == Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Alvaro> I think that was a good choice in general so thatAlvaro> possibly-data-eating bugs could be reported, but
there'saAlvaro> problem in the specific case of tuples carried over byAlvaro> pg_upgrade whose Multixact is "further in
thefuture" comparedAlvaro> to the nextMultiXactId counter. I think it's pretty clear thatAlvaro> we should let that
errorbe downgraded to DEBUG too, like theAlvaro> 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)
