Re: Rename max_parallel_degree?
От | Peter Eisentraut |
---|---|
Тема | Re: Rename max_parallel_degree? |
Дата | |
Msg-id | ac601d90-0a3f-5307-7132-bdf934712cce@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Rename max_parallel_degree? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Rename max_parallel_degree?
|
Список | pgsql-hackers |
On 10/12/16 7:58 PM, Robert Haas wrote: > I don't think it's wrong that the handling is done there, though. The > process that is registering the background worker is well-placed to > check whether there are already too many, and if it does not then the > slot is consumed at least temporarily even if it busts the cap. On > the flip side, the postmaster is the only process that is well-placed > to know when a background worker terminates. The worker process > itself can't be made responsible for it, as you suggest below, because > it may never even start up in the first place (e.g. fork() returns > EAGAIN). And the registering process can't be made responsible, > because it might die before the worker. Those are valid technical points. I have not worked out any alternatives. I'm concerned that all this makes background workers managed by extensions second-class citizens. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: