Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On Fri, Aug 25, 2017 at 6:25 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> I just had a quick glance over this and wondered about 2 things.
>
> 1. Why a GUC and not a new per user option so it can be configured
> differently for different users? Something like ALTER USER ... WORKER
> LIMIT <n>; perhaps. I mentioned about this up-thread a bit.
>
> 2.
>
> + if (count > max_worker_processes_per_user)
> + {
> + ereport(LOG,
> + (errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
> + errmsg("too many worker processes for role \"%s\"",
> + GetUserNameFromId(GetUserId(), false))));
> + LWLockRelease(BackgroundWorkerLock);
> + return false;
>
> Unless I've misunderstood something, it seems that this is going to
> give random errors to users which might only occur when they run
> queries against larger tables. Part of why it made sense not to count
> workers towards the CONNECTION LIMIT was the fact that we didn't want
> to throw these random errors when workers could not be obtained when
> we take precautions in other places to just silently have fewer
> workers. There's lots of discussions earlier in this thread about this
> and I don't think anyone was in favour of queries randomly working
> sometimes.

The status of the patch is incorrect I think. This was marked as needs
review but I can see some input here which has remained unanswered for
three months. I am marking this patch as returned with feedback.
--
Michael