On June 8, 2015 7:06:31 PM GMT+02:00, Alvaro Herrera <alvherre@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.