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