Tom Lane wrote:
> Jonathan Katz <jonathan.katz@excoventures.com> writes:
> > I see this one
> > > Fix potential data corruption when freezing a tuple whose XMAX is a multixact with exactly one
still-interestingmember
> > But I’m unsure how prevalent it is and if it should be highlighted.
>
> I'm not sure about that either. I do not think anyone did the legwork
> to determine the exact consequences of that bug, or the probability of
> someone hitting it in the field. But I think the latter must be really
> low, because we haven't heard any field reports that seem to match up.
My assessment is that that bug is extremely hard to hit. The main
conditions are, according to FreezeMultiXactId, that
1) the tuple must have a multixact xmax; and
2) the update xid must be newer than the cutoff freeze xid;
3) the multixact itself must be older than the cutoff freeze multi.
so the multixact counter needs to go faster than the xid counter (in
terms of who gets past the freeze age first), and a vacuum freeze must
be attempted on that tuple before the update xid becomes freezable.
The consequence is that the infomask, instead of ending up as
frz->t_infomask = tuple->t_infomask; frz->t_infomask &= ~HEAP_XMAX_BITS; |=
HEAP_XMAX_COMMITTED; tuple->t_infomask = frz->t_infomask;
is instead
frz->t_infomask = tuple->t_infomask; frz->t_infomask &= ~HEAP_XMAX_BITS; &=
HEAP_XMAX_COMMITTED; tuple->t_infomask = frz->t_infomask;
so any bit other than XMAX_COMMITTED is turned off -- which could be
pretty bad for HEAP_HASNULL, etc.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services