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

On 2014-07-21 12:43:24 -0400, Tom Lane wrote:
> 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.

I wonder if GetTopTransactionId()/MultiXactIdSetOldestMember() and using
lastSane* = ReadNew* isn't sufficient. After the xid assignment
concurrent GetOldest* can't go below the ReadNew* values anymore, right?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services