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
