On Fri, Sep 6, 2019 at 6:32 AM Jeremy Schneider <schnj...@amazon.com> wrote: > It really appears that it was the autovacuum process itself that was > providing the oldest running multixact which caused errors on yesterday's > attempts to vacuum other tables - even though I though vacuum processes were > ignored by that code. I'll have to take another look at some point.
Ah, that seems plausible. If the backend ever called GetMultiXactIdMembers() and thence MultiXactIdSetOldestVisible() at a time when there were live multixacts, it would set its own OldestVisibleMXactID[] slot, and then GetOldestMultiXactId() would return that value for the rest of the transaction (unless there was an even older one to return, but in the case you're describing there wasn't). GetOldestMultiXactId() doesn't have a way to ignore vacuum backends, like GetOldestXmin() does. That doesn't seem to be a problem in itself. (I am not sure why GetOldestMultiXactId() needs to consider OldestVisibleMXactId[] at all for this purpose, and not just OldestMemberXactId[], but I suppose it has to do with simultaneously key-share-locked and updated tuples or something, it's too early and I haven't had enough coffee.) -- Thomas Munro https://enterprisedb.com
