Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On Tue, Jan 17, 2017 at 4:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Amit's chosen yet another possible place to insert the guard: teach
> autovacuum that if a worker skips at least one table due to concurrent
> autovacuum activity AND ends up vacuuming no tables, don't call
> vac_update_datfrozenxid().  Since there is or was another worker
> running, vac_update_datfrozenxid() either already has been called or
> will be when that worker finishes.  So that seems safe.  If his patch
> were changed to skip vac_update_datfrozenxid() in all cases where we
> do nothing rather than only when we skip a table due to concurrent
> activity, we'd reintroduce the dropped-database problem that was fixed
> by 794e3e81a0e8068de2606015352c1254cb071a78.

After sleeping on this, I'm inclined to go with Amit's fix for now.
It seems less likely to break anything in the back-branches than any
other option I can think up.

An updated version of that patch is attached.  I changed the "if"
statement to avoid having an empty "if" clause and a non-empty "else"
clause, and I rewrote the comment based on my previous analysis.

Barring objections, I'll commit and back-patch this version.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers