Hi, Tom Lane <t...@sss.pgh.pa.us> writes: >> The user may not care about the difference, but there's a point in >> having the limit be the simpler concept of "this is the maximum amount >> of processes running vacuum at any time". The launcher is very >> uninteresting to users.
Adding to this, the launcher will not consume maintenance_work_mem whereas each worker is able to allocate that much, IIUC. > I committed things that way, but I'm still not convinced that we > shouldn't expose the launcher in pg_stat_activity. The thing that > is bothering me is that it is now able to take locks and potentially > could block some other process or even participate in a deadlock. > Do we really want to have entries in pg_locks that don't match any > entry in pg_stat_activity? Having the launcher locks show as such gets my vote too, but then I'm following on your opinion that a launcher ain't a worker and that users need to know about it. Let's keep the autovacuum_max_workers GUC naming, not counting the "there can be only one" launcher so that we're able to size maintenance_work_mem. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers