On Fri, Sep 6, 2019 at 6:32 AM Jeremy Schneider <schnjere@amazon.com> wrote:
> It really appears that it was the autovacuum process itself that was providing the oldest running multixact which
causederrors on yesterday's attempts to vacuum other tables - even though I though vacuum processes were ignored by
thatcode. 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