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

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CONNECTION LIMIT and Parallel Query don't play well together
Date: 2017-01-12 02:24:35
Message-ID: CAKJS1f_5=Aiu+0g7YW8g7GCGOKaqE_EFyiUVgCiSpdJc42Y9gA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 12 January 2017 at 09:36, Robert Haas <robertmhaas(at)gmail(dot)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

Attachment Content-Type Size
connection_limit_ignore_bgworkers_v1.patch application/octet-stream 3.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Ramsey 2017-01-12 02:29:16 Re: Retiring from the Core Team
Previous Message Michael Paquier 2017-01-12 01:21:17 Re: An isolation test for SERIALIZABLE READ ONLY DEFERRABLE