On Sun, Feb 20, 2022 at 2:15 PM Andres Freund <and...@anarazel.de> wrote: > We could e.g. add an error if FreezeMultiXactId() needs to create a new > multixact for a far-in-the-past xid. That's not great, of course, but if we > include the precise cause (pid of backend / prepared xact name / slot name / > ...) necessitating creating a new multi, it'd still be a significant > improvement over the status quo.
There are databases that have large tables (that grow and grow), and also have tables that need to allocate many MultiXacts (or lots of member space, at least). I strongly suspect that these are seldom the same table, though. The current inability of the system to recognize this difference seems like it might be a real problem. Why should big tables that contain no actual MultiXactIds at all (and never contained even one) get early anti-wraparound VACUUMs, specifically focussed on averting MultiXact wraparound? I'm hoping that the patch that adds smarter tracking of final relfrozenxid/relminmxid values during VACUUM makes this less of a problem automatically. -- Peter Geoghegan
