Andres Freund wrote: > A first version to address this problem can be found appended to this > email. > > Basically it does: > * Whenever more than MULTIXACT_MEMBER_SAFE_THRESHOLD are used, signal > autovacuum once per members segment > * For both members and offsets, once hitting the hard limits, signal > autovacuum everytime. Otherwise we loose the information when > restarting the database, or when autovac is killed. I ran into this a > bunch of times while testing. Sounds reasonable. I see another hole in this area. See do_start_worker() -- there we only consider the offsets limit to determine a database to be in almost-wrapped-around state (causing emergency attention). If the database in members trouble has no pgstat entry, it might get completely ignored. I think the way to close this hole is to find_multixact_start() in the autovac launcher for the database with the oldest datminmxid, to determine whether we need to activate emergency mode for it. (Maybe instead of having this logic in autovacuum, it should be a new function that receives database datminmulti and returns a boolean indicating whether the database is in trouble or not.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
