Andres Freund wrote: > I think the bugfix is going to have to essentially be something similar > to FreezeMultiXactId(). I.e. when reusing an old tuple's xmax for a new > tuple version, we need to prune dead multixact members. I think we can > do so unconditionally and rely on multixact id caching layer to avoid > unnecesarily creating multis when all members are the same.
Actually, isn't the cache subject to the very same problem? If you use a value from the cache, it could very well be below whatever the cutoff multi was chosen in the other process ... -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
