From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MultiXactId error after upgrade to 9.3.4 |
Date: | 2016-06-17 17:34:57 |
Message-ID: | 20160617173457.GA125666@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth wrote:
> >>>>> "Alvaro" == Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>
> >> (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.)
>
> Alvaro> HeapTupleSatisfiesVacuum removes very old multixacts
>
> It does nothing of the kind; it only marks them HEAP_XMAX_INVALID. The
> actual mxid remains in the tuple xmax field.
>
> The failing mxids in the case I analyzed on -bugs are failing _in spite
> of_ being already hinted HEAP_XMAX_INVALID, because the code path in
> question doesn't check that.
Ah, right. I had some code to reset HEAP_XMAX_IS_MULTI early on but
somebody didn't like it and we removed it; and we also removed some of
the checks for HEAP_XMAX_INVALID we had, or perhaps didn't extend them
to every place that needed them. It's not critical now anyway; the
patch I posted (or some variation thereof) should suffice as a fix.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-06-17 17:35:04 | Re: 10.0 |
Previous Message | Alvaro Herrera | 2016-06-17 17:04:47 | Re: 10.0 |