On Wed, Jul 3, 2013 at 11:19 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> 3) Why not adding an other function in worker_spi.c being the opposite >> of worker_spi_launch to stop dynamic bgworkers for a given index >> number? This would be only a wrapper of pg_terminate_backend, OK, but >> at least it would give the user all the information needed to start >> and to stop a dynamic bgworker with a single extension, here >> worker_spi.c. It can be painful to stop > > Well, there's currently no mechanism for the person who starts a new > backend to know the PID of the process that actually got started. I > plan to write a patch to address that problem, but it's not this > patch. OK. Understood, this functionality would be a good addition to have.
>> 4) Not completely related to this patch, but one sanity check in >> SanityCheckBackgroundWorker:bgworker.c is not listed in the >> documentation: when requesting a database connection, bgworker needs >> to have access to shmem. It looks that this should be also fixed in >> REL9_3_STABLE. > > That's fine; I think it's separate from this patch. Please feel free > to propose something. I'll send a patch about that. >> 6) Just wondering something: it looks that the current code is not >> able to identify what was the way used to start a given bgworker. >> Would it be interesting to be able to identify if a bgworker has been >> registered though RegisterBackgroundWorker or >> RegisterDynamicBackgroundWorker? > > I don't think that's a good thing to expose. My concerns here are covered by the functionality you propose in 1), where a user who launched a custom bgworker would know its PID, this would allow users to keep track of which bgworker has been started dynamically. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers