Re: [COMMITTERS] pgsql: Allow background workers to be started dynamically. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Allow background workers to be started dynamically.
Date
Msg-id 20130719125250.GH20525@alap2.anarazel.de
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Allow background workers to be started dynamically.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Allow background workers to be started dynamically.
List pgsql-hackers
Hi,

On 2013-07-19 08:23:25 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2013 at 7:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > The changes here make it impossible to write a bgworker which properly
> > works in 9.3 and 9.4. Was that intended? If so, the commit message
> > should mention the compatibility break...
>
> Yeah, sorry, I probably should have mentioned that.  The structure
> needs to be fixed size for us to store it in shared memory.

> > If it was intended I propose changing the signature for 9.3 as
> > well. There's just no point in releasing 9.3 when we already know which
> > trivial but breaking change will be required for 9.4
>
> I think that would be a good idea.

> And I'd also propose getting rid
> of bgw_sighup and bgw_sigterm in both branches, while we're at it.
> AFAICT, they don't add any functionality, and they're basically
> unusable for dynamically started background workers.  Probably better
> not to get people to used to using them.

I don't have a problem with getting rid of those, it's easy enough to
register them inside the worker and it's safe since we start with
blocked signals. I seem to remember some discussion about why they were
added but I can't find a reference anymore. Alvaro, do you remember?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [COMMITTERS] pgsql: Allow background workers to be started dynamically.
Next
From: Robert Haas
Date:
Subject: Re: getting rid of SnapshotNow