On Fri, Jun 17, 2016 at 9:33 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> "Robert" == Robert Haas <robertmh...@gmail.com> writes: > >> Why is the correct rule not "check for and ignore pre-upgrade mxids > >> before even trying to fetch members"? > > Robert> I entirely believe that's the correct rule, but doesn't > Robert> implementing it require a crystal balll? > > Why would it? Pre-9.3 mxids are identified by the combination of flag > bits in the infomask, see Alvaro's patch.
I see the patch, but I don't see much explanation of why the patch is correct, which I think is pretty scary in view of the number of mistakes we've already made in this area. The comments just say: + * A tuple that has HEAP_XMAX_IS_MULTI and HEAP_XMAX_LOCK_ONLY but neither of + * XMAX_EXCL_LOCK and XMAX_KEYSHR_LOCK must come from a tuple that was + * share-locked in 9.2 or earlier and then pg_upgrade'd. Why must that be true? + * We must not try to resolve such multixacts locally, because the result would + * be bogus, regardless of where they stand with respect to the current valid + * range. What about other pre-upgrade mxacts that don't have this exact bit pattern? Why can't we try to resolve them and end up in trouble just as easily? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
