Re: MultiXactId error after upgrade to 9.3.4 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: MultiXactId error after upgrade to 9.3.4
Date
Msg-id 20160621221543.GA123505@alvherre.pgsql
Whole thread Raw
In response to Re: MultiXactId error after upgrade to 9.3.4  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Fri, Jun 17, 2016 at 9:33 AM, Andrew Gierth
> > <andrew@tao11.riddles.org.uk> wrote:
> > >>>>>> "Robert" == Robert Haas <robertmhaas@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.
>
> ... and actually the patch fails one isolation tests in 9.3, which is
> why I haven't pushed (I haven't tested 9.4 but I suppose it should be
> the same).  I'm looking into that now.

Ah, it should have been obvious; the reason it's failing is because 9.3
and 9.4 lack commit 27846f02c176 which removed
MultiXactHasRunningRemoteMembers(), so the straight backpatch plus
conflict fixes left one GetMultiXactIdMembers call with the allow_old
flag to true.  The attached patch fixes that omission.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Requesting external_pid_file with postgres -C when not initialized lead to coredump
Next
From: Bruce Momjian
Date:
Subject: Re: Speaking of breaking compatibility...standard_conforming_strings