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