On Mon, Mar 24, 2014 at 11:03 PM, Magnus Hagander <mag...@hagander.net> wrote: > That's what I thought. Can a dynamic background worker start *another* > dynamic background worker, or can they only be started from "first level" > background workers? I have never really tried by myself, but I don't see any reason why it wouldn't work as it is only a matter of doing what is for example in worker_spi_launch:worker_spi.c. Btw, a bgworker could also behave like a "regular backend" as mentioned in the docs, so a regular backend is just a subclass of a bgworker :)
>> > Also: >> > "Background workers are expected to be continuously running; if they >> > exit >> > cleanly, postgres will restart them immediately. " >> > >> > This doesn't apply to dynamic ones, which we might want to clarify. Do >> > we >> > have a "term" for non-dynamic background workers? "static workers"? >> In the code or the documentation, there is no explicit >> differentiation, bgworkers are either called plainly "bgworker", or >> "dynamic bgworker". Perhaps the solution here is simply to say >> "background workers started by the postmaster are expected blabla". > That, or we need to invite a term for it? Hm... Seems like an overkill. The main difference between a non-dynamic and dynamic bgworker is the way they are registered. "Static" bgworkers use RegisterBackgroundWorker that can only be called in _PG_init when a module is loaded with shared_preload_libraries. Dynamic bgworkers use RegisterDynamicbackgroundWorker. And this differentiation is clearly done in the 2nd paragraph. So perhaps the solution here is simply to write "Background workers registered with RegisterBackgroundWorker are expected...". I am not a native English speaker, but "static" sounds like a daemon process that has to restart, and a bgworker could perform a one-time task as well. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
