From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: dynamic background workers, round two |
Date: | 2013-08-27 13:56:36 |
Message-ID: | 20130827135636.GB29621@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-07-26 08:50:51 -0400, Robert Haas wrote:
> > > > Btw, you seem to want to support this in bgworkers started by a
> > > > bgworker. That's not going to work without some changes if the
> > > > "intermediate" bgworker is one without a backend since those don't use
> > > > procsignal_sigusr1_handler.
> > > Right. I think it's OK for now to limit it to cases where the
> > > intermediate bgworker has a backend. If someone else finds that
> > > restriction unacceptable, they can fix it.
> > I don't have a problem with the restriction, but I'd like to see a check
> > against it. Maybe check for MyBackendId != InvalidBackendId in
> > RegisterDynamicBackgroundWorker()? That would also prevent starting
> > further bgworkers before BackgroundWorkerInitializeConnection() is done
> > in a connected bgworker which seems to be a good thing.
>
> Well, that's easy enough to fix. Should we Assert() or elog() or
> what?
I think that's not in the patch yet either.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-08-27 14:07:33 | Re: dynamic shared memory |
Previous Message | Andres Freund | 2013-08-27 13:50:25 | Re: dynamic background workers, round two |