Re: Rename max_parallel_degree?

On Thu, Oct 27, 2016 at 3:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Oct 24, 2016 at 4:04 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > On 10/12/16 7:58 PM, Robert Haas wrote:
> >> I don't think it's wrong that the handling is done there, though. The
> >> process that is registering the background worker is well-placed to
> >> check whether there are already too many, and if it does not then the
> >> slot is consumed at least temporarily even if it busts the cap. On
> >> the flip side, the postmaster is the only process that is well-placed
> >> to know when a background worker terminates. The worker process
> >> itself can't be made responsible for it, as you suggest below, because
> >> it may never even start up in the first place (e.g. fork() returns
> >> EAGAIN). And the registering process can't be made responsible,
> >> because it might die before the worker.
> >
> > Those are valid technical points. I have not worked out any
> alternatives.
> >
> > I'm concerned that all this makes background workers managed by
> > extensions second-class citizens.
>
> I suppose at some level that's true, but I have a hard time getting
> worked up about it. There are always some areas where core code is
> going to be privileged over non-core code, but I'd say that background
> workers stand out as a shining example of enabling interesting
> non-core code. In fact, the main reason why this patch exists at all
> is so that the sole in-core user of the background worker facility -
> parallel query - doesn't crowd out interesting non-core uses of that
> facility. This isn't a parallel query feature; it's an
> everything-that-uses-background-workers-that-is-not-parallel-query
> feature.
>
> Also, for many types of background workers, this kind of limiting
> behavior isn't really useful or doesn't really make sense. Obviously,
> any application that uses exactly one background worker (or any fixed
> number of background workers) doesn't need any feature similar to this
> one. Also, any application that uses a "launcher" process and some
> number of per-database workers can limit the number of workers it
> consumes by teaching the launcher process to enforce a limit. These
> two patterns are quite common, I think, and probably cover a lot of
> what background workers might like to do. Parallel query is a little
> bit unusual in that any backend in the system might launch workers
> without having any idea what workers other backends are already doing.
> It seems unlikely to me that many extensions would share this pattern,
> but perhaps I lack sufficient imagination. pg_background, or any
> facility derived from it, might qualify, but I can't think what else
> would.
>
> In any event, this is not written in stone. I don't think it would be
> a huge deal to change this later if we come up with something better.
>

From the recent mails, it is not clear to me what is the status of this
patch.
moved to next CF with "needs review" state. Please feel free to update
the status.

Regards,
Hari Babu
Fujitsu Australia