On 2017-11-04 06:15:00 -0700, Andres Freund wrote: > The current testcase, and I think the descriptions in the relevant > threads, all actually fail to point out the precise way the bug is > triggered. As e.g. evidenced that the freeze-the-dead case appears to > not cause any failures in !assertion builds even if the bug is present.
Trying to write up tests reproducing more of the issues in the area, I think I might have found a third issue - although I'm not sure how practically relevant it is: When FreezeMultiXactId() decides it needs to create a new multi because the old one is below the cutoff, that attempt can be defeated by the multixact id caching. If the new multi has exactly the same members the multixact id cache will just return the existing multi with the same members. The cache will routinely be primed from the lookup of its members. I'm not yet sure how easily this can be hit in practice, because commonly the multixact horizon should prevent a multi with all its members living from being below the horizon. I found a situation where that's not the case with the current bug, but I'm not sif that can happen otherwise. Greetings, Andres Freund -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
