Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> I'm not wondering so much about vac_update_relstats(). There indeed the
> calls aren't new and the worst that can happen is a slightly older
> freeze limit. I'm more wondering about vac_update_datfrozenxid(). Afaics
> we very well could hit
> newFrozenXid = lastSaneFrozenXid = GetOldestXmin(NULL, true);
> newMinMulti = lastSaneMinMulti = GetOldestMultiXactId();
> for a relation that has just been vacuumed by another backend.

Hmm ... I see. The issue is not what the computed minimum datfrozenxid
etc should be; it's right to err in the backwards direction there.
It's whether we want to declare that the calculation is bogus and abandon
truncation if another session manages to sneak in a very-new relfrozenxid.
Yeah, you're right, we need to be conservative about doing that. I'd
wanted to avoid extra calls here but I guess we have to do them after all.
Will fix.

regards, tom lane