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

On Tue, Jan 17, 2017 at 4:02 PM, Robert Haas <robertmhaas(at)gmail(dot)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