Re: autovacuum scheduling starvation and frenzy

Robert Haas wrote:

> This kind of seems like throwing darts at the wall.  It could be
> better if we are right to skip the database already being vacuumed for
> wraparound, or worse if we're not.

Well, it only skips the DB for half the naptime interval, so that other
databases have a chance to be chosen before that.  If you set up a
nonsensical interval such as one day, this might be problematic.

(I'm not sure I understand the darts analogy.)

Maybe instead of some interval we could have a flag that alternates
between on and off: let one other database be chosen, then the one in
danger, then some other database again.  But if you have large numbers
of databases, this isn't a very solution; you only waste half the
workers rather than all of them .. meh.

Here's another idea: have a counter of the number of tables that are in
danger of xid/multixact wraparound; only let that many workers process
the database in a row.  Of course, the problem is how to determine how
many tables are in danger when we haven't even connected to the database
in the first place.  We could try to store a counter in pgstats, ugh.
Or have the first for-wraparound worker store a number in shared memory
which launcher can read.  Double ugh.


> I'm not sure that we should do this at all, or at least not without
> testing it extensively first.  We could easily shoot ourselves in the
> foot.

Well, we need to do *something*, because having workers directed towards
a database on which they can't do any good causes problems too -- other
databases accumulate bloat in the meantime.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services