Re: autovacuum launcher using InitPostgres
От | Dimitri Fontaine |
---|---|
Тема | Re: autovacuum launcher using InitPostgres |
Дата | |
Msg-id | m21vmr64p3.fsf@hi-media.com обсуждение исходный текст |
Ответ на | Re: autovacuum launcher using InitPostgres (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: