Tom Lane wrote: > While I haven't yet tested it, it seems like a fix might be as simple > as deleting these lines in maybe_start_bgworker: > > /* > * Have ServerLoop call us again. Note that there might not > * actually *be* another runnable worker, but we don't care all > * that much; we will find out the next time we run. > */ > StartWorkerNeeded = true; > return; > > So I'm wondering what the design rationale was for only starting one > bgworker per invocation.
The rationale was that there may be other tasks waiting for postmaster attention, and if there are many bgworkers needing to be started, the other work may be delayed for a long time. This is not the first time that this rationale has been challenged, but so far there hasn't been any good reason to change it. One option is to just remove it as you propose, but a different one is to stop using select(2) in ServerLoop, because those behavior differences seem to make it rather unusable. > It also appears to me that do_start_bgworker's treatment of fork > failure is completely brain dead. Did anyone really think about > that case? Hmm, I probably modelled it on autovacuum without giving that case much additional consideration. -- Álvaro Herrera https://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
