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
On Wed, Apr 16, 2014 at 5:27 AM, Petr Jelinek p...@2ndquadrant.com 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
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 Mon, Mar 24, 2014 at 5:54 PM, Magnus Hagander mag...@hagander.net 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
On Mon, Mar 24, 2014 at 12:20 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Mar 24, 2014 at 5:54 PM, Magnus Hagander mag...@hagander.net
wrote:
I was looking at
http://www.postgresql.org/docs/devel/static/bgworker.html
with a client today.
It says:
Unlike
On Mon, Mar 24, 2014 at 11:03 PM, Magnus Hagander mag...@hagander.net 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
On Tue, Aug 27, 2013 at 9:50 AM, Andres Freund and...@2ndquadrant.com wrote:
BgwHandleStatus GetBackgroundWorkerPid(BackgroundWorkerHandle *handle,
pid_t *pid);
BgwHandleStatus WaitForBackgroundWorkerStartup(BackgroundWorkerHandle
*handle, pid_t *pid);
OK, here's a patch that API. I
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas robertmh...@gmail.com 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
On 2013-08-28 14:04:59 -0400, Robert Haas wrote:
+ functionRegisterDynamicBackgroundWorker(typeBackgroundWorker
+ *worker, BackgroundWorkerHandle **handle/type)/function. Unlike
+ functionRegisterBackgroundWorker/, which can only be called from
within
+ the postmaster,
Hi Robert,
On 2013-08-17 12:08:17 -0400, Robert Haas wrote:
On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund and...@anarazel.de wrote:
So, I'd suggest something like:
typedef enum BgwHandleStatus {
BGWH_SUCCESS, /* sucessfully got status */
BGWH_NOT_YET, /* worker hasn't started
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.
On Sun, Aug 11, 2013 at 1:31 AM, Andres Freund and...@anarazel.de 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
[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 robertmh...@gmail.com wrote:
On Fri, Jul 26, 2013 at 5:34 AM, Andres Freund and...@2ndquadrant.com
wrote:
It doesn't
On 2013-07-25 12:35:30 -0400, Robert Haas wrote:
On Wed, Jul 24, 2013 at 5:34 PM, Andres Freund and...@2ndquadrant.com 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,
On Fri, Jul 26, 2013 at 5:34 AM, Andres Freund and...@2ndquadrant.com 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
On Wed, Jul 24, 2013 at 5:34 PM, Andres Freund and...@2ndquadrant.com 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
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
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,
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund and...@2ndquadrant.comwrote:
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
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund and...@2ndquadrant.comwrote:
--- 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
On 2013-07-25 08:03:17 +0900, Michael Paquier wrote:
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund and...@2ndquadrant.comwrote:
--- 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
On Thu, Jul 25, 2013 at 8:05 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-07-25 08:03:17 +0900, Michael Paquier wrote:
On Thu, Jul 25, 2013 at 6:34 AM, Andres Freund and...@2ndquadrant.com
wrote:
--- a/contrib/worker_spi/worker_spi.c
+++ b/contrib/worker_spi/worker_spi.c
On Wed, Jul 3, 2013 at 11:15 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
michael.paqu...@gmail.com 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
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 surprised
On Wed, Jul 3, 2013 at 11:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 24, 2013 at 3:51 AM, Michael Paquier
michael.paqu...@gmail.com 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
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 robertmh...@gmail.com wrote:
The second patch, dynamic-bgworkers-v1.patch, revises the background
worker API to allow background workers to be started
On Mon, Jun 17, 2013 at 10:45 PM, Peter Eisentraut pete...@gmx.net 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
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
On Thu, Jun 20, 2013 at 9:57 AM, Markus Wanner mar...@bluegap.ch 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.
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 10:59 AM, Markus Wanner mar...@bluegap.ch 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,
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
database
Hi,
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas robertmh...@gmail.com 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:
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
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 server
On 14 June 2013 22:00, Robert Haas robertmh...@gmail.com 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
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas robertmh...@gmail.com 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,
39 matches
Mail list logo
