On 04/17/2014 12:16 AM, Robert Haas wrote:
> On Wed, Apr 16, 2014 at 7:11 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> - A flag like BGW_UNREGISTER_ON_RESTART;
>
> I would be OK with this, maybe modulo the name.
>
>> - To always unregister dynamic bgws on postmaster shm clear + restart;
>
> I don't particularly care for this. Let's suppose the background
> worker is a long-running daemon, like a PG equivalent of cron. In
> static-background worker land, the admin has to restart the cluster to
> get this going. In dynamic-background worker land, he can load it on
> the fly. But once he gets it up and running, he wants it to stay up
> and running, surviving crashes and everything. That's a big part of
> the value of having a background worker interface in the first place.
It'd be the job of the extension that provides the bgworker to make sure
that it gets relaunched on postmaster restart.
I tend to agree though. The problem I'm describing only causes issues
for extensions that launch dynamic bgworkers during extension startup.
Extensions that launch bgworkers in response to SQL commands and don't
rely on passing state to the bgworker via shared memory shouldn't have
to deal with restarting them on postmaster restart.
>
>> - A way to list bgws, inspect their BackgroundWorker structs and obtain
>> their handles; or
>
> This is certainly a good idea.
>
>> - A way to idempotently register a bgw only if it doesn't already exist
>
> This is probably a good idea, too.
I think we need _one_ solution for 9.4, and need it soon.
The simplest is probably to flush all dynamic bgworkers. But I think
you're probably right - that solves the problem discussed here, but is
likely to make life harder for other use cases.
A last-minute API addition for bgworker listing/inspection might not be
a great idea - it's too late for it to see much testing and analysis and
it might introduce bigger API problems than it solves.
Duplicate-free registration might be OK, but there are some questions
around how we'd handle differing parameters, what should be the
determinant for uniquenes, whether we should go for idempotency or
return/raise an error to indicate it already exists, etc. So similar
issue with doing it at the last minute.
To me, that says "let's add a flag to allow a dynamic bgworker to be
unregistered on postmaster restart". Seems simple and low risk.
I'll follow up with a proposed patch, then we can spend some quality
shed time on the flag name ;-)
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services