On Fri, Feb 25, 2022 at 2:00 PM Peter Geoghegan <p...@bowt.ie> wrote: > > Hm. I guess I'll have to look at the code for it. It doesn't immediately > > "feel" quite right. > > I kinda think it might be. Please let me know if you see a problem > with what I've said.
Oh, wait. I have a better idea of what you meant now. The loop towards the end of FreezeMultiXactId() will indeed "Determine whether to keep this member or ignore it." when we need a new MultiXactId. The loop is exact in the sense that it will only include those XIDs that are truly needed -- those that are still running. But why should we ever get to the FreezeMultiXactId() loop with the stuff from 0002 in place? The whole purpose of the loop is to handle cases where we have to remove *some* (not all) XIDs from before cutoff_xid that appear in a MultiXact, which requires careful checking of each XID (this is only possible when the MultiXactId is < cutoff_multi to begin with, which is OldestMxact in the patch, which is presumably very recent). It's not impossible that we'll get some number of "skewed MultiXacts" with the patch -- cases that really do necessitate allocating a new MultiXact, just to "freeze some XIDs from a MultiXact". That is, there will sometimes be some number of XIDs that are < OldestXmin, but nevertheless appear in some MultiXactIds >= OldestMxact. This seems likely to be rare with the patch, though, since VACUUM calculates its OldestXmin and OldestMxact (which are what cutoff_xid and cutoff_multi really are in the patch) at the same point in time. Which was the point I made in my email yesterday. How many of these "skewed MultiXacts" can we really expect? Seems like there might be very few in practice. But I'm really not sure about that. -- Peter Geoghegan
