Re: [HACKERS] dynamic background workers, round two

2013-08-28 Thread Andres Freund
On 2013-08-28 14:04:59 -0400, Robert Haas wrote: > >> + RegisterDynamicBackgroundWorker(BackgroundWorker > >> + *worker, BackgroundWorkerHandle **handle). Unlike > >> + RegisterBackgroundWorker, which can only be called from > >> within > >> + the postmaster, RegisterDynamicBackgroundWorker

Re: [HACKERS] dynamic background workers, round two

2013-08-28 Thread Robert Haas
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas wrote: >> Hm. Not this patches fault, but We seem to allow bgw_start_time == >> BgWorkerStart_PostmasterStart here which doesn't make sense... > > I can add a check for that. I agree that it's a separate patch. On third thought, is there really any po

Re: [HACKERS] dynamic background workers, round two

2013-08-28 Thread Robert Haas
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas wrote: > I certainly can't promise that the code is bug-free. But I think it's > probably better to get this into the tree and let people start playing > around with it than to continue to maintain it in my private sandbox. > At this point it's just in

Re: [HACKERS] dynamic background workers, round two

2013-08-28 Thread Robert Haas
On Tue, Aug 27, 2013 at 9:50 AM, Andres Freund wrote: >> > BgwHandleStatus GetBackgroundWorkerPid(BackgroundWorkerHandle *handle, >> > pid_t *pid); >> > BgwHandleStatus WaitForBackgroundWorkerStartup(BackgroundWorkerHandle >> > *handle, pid_t *pid); >> >> OK, here's a patch that API. I renamed

Re: [HACKERS] dynamic background workers, round two

2013-08-27 Thread Andres Freund
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_h

Re: [HACKERS] dynamic background workers, round two

2013-08-27 Thread Andres Freund
Hi Robert, On 2013-08-17 12:08:17 -0400, Robert Haas wrote: > On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund wrote: > > So, I'd suggest something like: > > > > typedef enum BgwHandleStatus { > >BGWH_SUCCESS, /* sucessfully got status */ > >BGWH_NOT_YET, /* worker hasn't started yet */ > >

Re: [HACKERS] dynamic background workers, round two

2013-08-17 Thread Robert Haas
On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund wrote: > So, I'd suggest something like: > > typedef enum BgwHandleStatus { >BGWH_SUCCESS, /* sucessfully got status */ >BGWH_NOT_YET, /* worker hasn't started yet */ >BGWH_GONE, /* worker had been started, but shut down already */ >BG

Re: [HACKERS] dynamic background workers, round two

2013-08-10 Thread Andres Freund
[sent again, previously sent as reply, instead of reply-all, thanks Robert] On 2013-08-09 09:09:08 -0400, Robert Haas wrote: > On Fri, Jul 26, 2013 at 8:50 AM, Robert Haas wrote: > > On Fri, Jul 26, 2013 at 5:34 AM, Andres Freund > > wrote: > >> It doesn't need to be the postmaster, but I think

Re: [HACKERS] dynamic background workers, round two

2013-07-26 Thread Robert Haas
On Fri, Jul 26, 2013 at 5:34 AM, Andres Freund wrote: > It doesn't need to be the postmaster, but I think we need to provide > central infrastructure for that. I don't want this to end up being > redone poorly in multiple places. > I just wanted to mention it, it obviously doesn't need to be imple

Re: [HACKERS] dynamic background workers, round two

2013-07-26 Thread Andres Freund
On 2013-07-25 12:35:30 -0400, Robert Haas wrote: > On Wed, Jul 24, 2013 at 5:34 PM, Andres Freund wrote: > > This seems like a sensible idea to me. But, in the context of dynamic > > query, don't we also need the reverse infrastructure of notifying a > > bgworker that the client, that requested it

Re: [HACKERS] dynamic background workers, round two

2013-07-25 Thread Robert Haas
On Wed, Jul 24, 2013 at 5:34 PM, Andres Freund wrote: > This seems like a sensible idea to me. But, in the context of dynamic > query, don't we also need the reverse infrastructure of notifying a > bgworker that the client, that requested it to be started, has died? > Ending up with a dozen bgwork

Re: [HACKERS] dynamic background workers, round two

2013-07-24 Thread Michael Paquier
On Thu, Jul 25, 2013 at 8:05 AM, Andres Freund wrote: > On 2013-07-25 08:03:17 +0900, Michael Paquier wrote: > > On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund >wrote: > > > > > > --- a/contrib/worker_spi/worker_spi.c > > > > +++ b/contrib/worker_spi/worker_spi.c > > > > > > Btw, I've posted a mi

Re: [HACKERS] dynamic background workers, round two

2013-07-24 Thread Andres Freund
On 2013-07-25 08:03:17 +0900, Michael Paquier wrote: > On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund wrote: > > > > --- a/contrib/worker_spi/worker_spi.c > > > +++ b/contrib/worker_spi/worker_spi.c > > > > Btw, I've posted a minimal regression test for bworkers/worker_spi in > > 20130724175742.gd

Re: [HACKERS] dynamic background workers, round two

2013-07-24 Thread Michael Paquier
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund wrote: > > --- a/contrib/worker_spi/worker_spi.c > > +++ b/contrib/worker_spi/worker_spi.c > > Btw, I've posted a minimal regression test for bworkers/worker_spi in > 20130724175742.gd10...@alap2.anarazel.de - I'd like to see some coverage > of this..

Re: [HACKERS] dynamic background workers, round two

2013-07-24 Thread Michael Paquier
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund wrote: > Hi, > > On 2013-07-24 12:46:21 -0400, Robert Haas wrote: > > The attached patch attempts to remedy this problem. When you register > > a background worker, you can obtain a "handle" that can subsequently > > be used to query for the worker's

Re: [HACKERS] dynamic background workers, round two

2013-07-24 Thread Andres Freund
Hi, On 2013-07-24 12:46:21 -0400, Robert Haas wrote: > The attached patch attempts to remedy this problem. When you register > a background worker, you can obtain a "handle" that can subsequently > be used to query for the worker's PID. If you additionally initialize > bgw_notify_pid = MyProcPid

[HACKERS] dynamic background workers, round two

2013-07-24 Thread Robert Haas
The dynamic background workers patch that I submitted for CF1 was generally well-received, but several people commented on a significant limitation: there's currently no way for a backend that requests a new background worker to know whether that background worker was successfully started. If you'