* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > I think this rule is wrong. I think the rule ought to be something like
> > "if the XMAX_INVALID bit is set, then reset whatever is there if there
> > is something; if the bit is not set, proceed as today". Otherwise we
> > risk reading garbage, which is what is happening in this case.
>
> Andres asks on IM: How come there is garbage there in the first place?
> I have to admit I have no idea.
I haven't got any great explanation for that either. I continue to feel
that it's much more likely that it's an xid than a multixid. Is it
possible that it was stamped with a real xmax through some code path
which ignored the IS_MULTI flag? This could have been from as far back
as 9.0-era. On this over-7TB database, only this one tuple had the
issue. I have another set of databases which add up to ~20TB that I'm
currently testing an upgrade from 9.2 to 9.3 on and will certainly let
everyone know if I run into a similar situation there.
On our smallest DB (which we upgraded first) which is much more OLTP
instead of OLAP, we didn't run into this.
This is all on physical gear and we've seen no indications that there
has been any corruption. Hard to rule it out completely, but it seems
pretty unlikely.
Thanks,
Stephen