On 2014-07-21 12:43:24 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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