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