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. > 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. > 5) Why not adding some documentation? Both dynamic and static > bgworkers share the same infrastructure, so some lines in the existing > chapter might be fine? I'll take a look. > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
