Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together
Date
Msg-id CAKJS1f_5=Aiu+0g7YW8g7GCGOKaqE_EFyiUVgCiSpdJc42Y9gA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
> On 12 January 2017 at 09:36, Robert Haas <robertmhaas@gmail.com> wrote:
>> One option is certainly to decide categorically that background
>> workers are not connections, and therefore CountUserBackends() should
>> ignore them and InitializeSessionUserId() shouldn't call it when the
>> session being started is a background worker.  That means that
>> background workers don't count against the user connection limit, full
>> stop.

I've attached a patch which intended to assist discussions on this topic.

The patch adds some notes to the docs to mention that background
workers and prepared xacts are not counted in CONNECTION LIMIT, it
then goes on and makes CountUserBackends() ignore bgworkers. It was
already ignoring prepared xacts. There's a bit of plumbing work to
make the proc array aware of the background worker status. Hopefully
this is suitable. I'm not all that close to that particular area of
the code.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE
Next
From: Paul Ramsey
Date:
Subject: Re: [HACKERS] Retiring from the Core Team