>>>>> "Alvaro" == Alvaro Herrera <alvhe...@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