On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >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. > >I might be misreading the code, but PMSIGNAL_START_AUTOVAC_LAUNCHER >only >causes things to happen (i.e. a new worker to be started) when >autovacuum is disabled. If autovacuum is enabled, postmaster receives >the signal and doesn't do anything about it, because the launcher is >already running. Of course, regularly scheduled autovac workers will >eventually start running, but perhaps this is not good enough.
Well that's just the same for the plain xid precedent? I'd not mind improving further, but that seems like a separate thing. Andres --- Please excuse brevity and formatting - I am writing this on my mobile phone. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
