Re: dynamic background workers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamic background workers
Date: 2013-07-03 14:19:49
Message-ID: CA+TgmoZSXohQHxRXSh3QbbD49UOe+foY2Fg4N9EkWiR092EMMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-07-03 14:25:43 Re: refresh materialized view concurrently
Previous Message Kevin Grittner 2013-07-03 14:18:47 Re: refresh materialized view concurrently