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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
