On Wed, Apr 16, 2014 at 5:27 AM, Petr Jelinek wrote:
> Hello,
>
> I've been recently doing some work with dynamic bgworkers and noticed that I
> have no way of saying "I am done now and want to exit cleanly" because
> bgworkers get restarted automatically on exit code 0 no matter what is the
> res
Hello,
I've been recently doing some work with dynamic bgworkers and noticed
that I have no way of saying "I am done now and want to exit cleanly"
because bgworkers get restarted automatically on exit code 0 no matter
what is the restart interval set to.
I understand the rationale for this b
On Mon, Mar 24, 2014 at 11:03 PM, Magnus Hagander wrote:
> That's what I thought. Can a dynamic background worker start *another*
> dynamic background worker, or can they only be started from "first level"
> background workers?
I have never really tried by myself, but I don't see any reason why it
On Mon, Mar 24, 2014 at 12:20 PM, Michael Paquier wrote:
> On Mon, Mar 24, 2014 at 5:54 PM, Magnus Hagander
> wrote:
> > I was looking at
> http://www.postgresql.org/docs/devel/static/bgworker.html
> > with a client today.
> >
> > It says:
> > "Unlike RegisterBackgroundWorker, which can only be
On Mon, Mar 24, 2014 at 5:54 PM, Magnus Hagander wrote:
> I was looking at http://www.postgresql.org/docs/devel/static/bgworker.html
> with a client today.
>
> It says:
> "Unlike RegisterBackgroundWorker, which can only be called from within the
> postmaster,RegisterDynamicBackgroundWorker must be
I was looking at
http://www.postgresql.org/docs/devel/static/bgworker.htmlwith a client
today.
It says:
"Unlike RegisterBackgroundWorker, which can only be called from within the
postmaster,RegisterDynamicBackgroundWorker must be called from a regular
backend."
Is that the correct restriction? In
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
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
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
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
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
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 */
> >
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
[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
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
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
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
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
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
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..
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
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
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'
On Wed, Jul 3, 2013 at 11:15 AM, Alvaro Herrera
wrote:
> Andres Freund escribió:
>> Just as a datapoint, if you benchmark the numbers of forks that can be
>> performed by a single process (i.e. postmaster) the number is easily in
>> the 10s of thousands. Now forking that much has some scalability
On Wed, Jul 3, 2013 at 11:19 PM, Robert Haas wrote:
> On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
> 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
Andres Freund escribió:
> Just as a datapoint, if you benchmark the numbers of forks that can be
> performed by a single process (i.e. postmaster) the number is easily in
> the 10s of thousands. Now forking that much has some scalability
> implications inside the kernel, but still.
> I'd be surpri
On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
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 u
Hi,
Please find some review for the 2nd patch, with the 1st patch applied
on top of it.
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas wrote:
> The second patch, dynamic-bgworkers-v1.patch, revises the background
> worker API to allow background workers to be started dynamically.
> This requires s
On 2013-06-20 11:29:27 -0400, Robert Haas wrote:
> > Do you mean pre-forking and connecting to a specific database? Or really
> > just the forking?
>
> I've considered both at various times, although in this context I was
> mostly thinking about just the forking. Pre-connecting to a specific
> dat
On Thu, Jun 20, 2013 at 10:59 AM, Markus Wanner wrote:
> On 06/20/2013 04:41 PM, Robert Haas wrote:
>> The constant factor is also very small. Generally, I would expect
>> num_worker_processes <~ # CPUs
>
> That assumption might hold for parallel querying, yes. In case of
> Postgres-R, it doesn't
On 06/20/2013 04:41 PM, Robert Haas wrote:
> The constant factor is also very small. Generally, I would expect
> num_worker_processes <~ # CPUs
That assumption might hold for parallel querying, yes. In case of
Postgres-R, it doesn't. In the worst case, i.e. with a 100% write load,
a cluster of n
On Thu, Jun 20, 2013 at 9:57 AM, Markus Wanner wrote:
> That sounds like a good simplification. Even if it's an O(n) operation,
> the n in question here has relatively low practical limits. It's
> unlikely to be much of a concern, I guess.
The constant factor is also very small. Generally, I wou
Robert,
On 06/14/2013 11:00 PM, Robert Haas wrote:
> Parallel query, or any subset of that project such as parallel sort,
> will require a way to start background workers on demand.
thanks for continuing this, very much appreciated. Postgres-R and thus
TransLattice successfully use a similar appr
On Mon, Jun 17, 2013 at 10:45 PM, Peter Eisentraut wrote:
> On Fri, 2013-06-14 at 17:00 -0400, Robert Haas wrote:
>> Alvaro's work on 9.3, we now have the ability to configure background
>> workers via shared_preload_libraries. But if you don't have the right
>> library loaded at startup time, an
Hi,
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas wrote:
> The first patch, max-worker-processes-v1.patch, adds a new GUC
> max_worker_processes, which defaults to 8. This fixes the problem
> discussed here:
>
> http://www.postgresql.org/message-id/CA+TgmobguVO+qHnHvxBA2TFkDhw67Y=4bp405fvabec_eto
On Fri, 2013-06-14 at 17:00 -0400, Robert Haas wrote:
> Alvaro's work on 9.3, we now have the ability to configure background
> workers via shared_preload_libraries. But if you don't have the right
> library loaded at startup time, and subsequently wish to add a
> background worker while the serve
BTW, one of the ideas that popped up in the unConference session on
replication was "why couldn't we use a background worker as a replication
agent?"
The main reason pointed out was 'because that means you have to restart the
postmaster to add a replication agent.' (e.g. - like a Slony "slon"
pro
On 14 June 2013 22:00, Robert Haas wrote:
> Parallel query, or any subset of that project such as parallel sort,
> will require a way to start background workers on demand. Thanks to
> Alvaro's work on 9.3, we now have the ability to configure background
> workers via shared_preload_libraries. B
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas wrote:
> The second patch, dynamic-bgworkers-v1.patch, revises the background
> worker API to allow background workers to be started dynamically.
> This requires some communication channel from ordinary workers to the
> postmaster, because it is the po
39 matches
Mail list logo
