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

2017-08-25 Thread David Rowley
On 24 August 2017 at 11:15, Peter Eisentraut wrote: > Here is a slightly updated patch for consideration in the upcoming > commit fest. Hi Peter, 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

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

2017-08-23 Thread Peter Eisentraut
On 4/6/17 15:01, Peter Eisentraut wrote: > On 2/15/17 11:19, Peter Eisentraut wrote: >> So I would like to have a background worker limit per user, as you >> allude to. Attached is a patch that implements a GUC setting >> max_worker_processes_per_user. >> >> Besides the uses for background

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

2017-04-06 Thread Peter Eisentraut
On 2/15/17 11:19, Peter Eisentraut wrote: > So I would like to have a background worker limit per user, as you > allude to. Attached is a patch that implements a GUC setting > max_worker_processes_per_user. > > Besides the uses for background sessions, but it can also be useful for > parallel

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

2017-02-15 Thread Robert Haas
On Wed, Feb 15, 2017 at 11:19 AM, Peter Eisentraut wrote: > On 1/11/17 5:51 PM, David Rowley wrote: >> Now, since background workers >> don't consume anything from max_connections, then I don't really feel >> that a background worker should count towards

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

2017-02-15 Thread Peter Eisentraut
On 1/11/17 5:51 PM, David Rowley wrote: > Now, since background workers > don't consume anything from max_connections, then I don't really feel > that a background worker should count towards "CONNECTION LIMIT". I'd > assume any CONNECTION LIMITs that are set for a user would be > calculated based

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

2017-02-01 Thread Albe Laurenz
Andrew Dunstan wrote: > On 01/29/2017 04:07 PM, David Rowley wrote: >> Looks like there's a few other usages of CountDBBackends() which >> require background workers to be counted too, so I ended up creating >> CountDBConnections() as I didn't really think adding a bool flag to >> CountDBBackends

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

2017-02-01 Thread Andrew Dunstan
On 01/29/2017 04:07 PM, David Rowley wrote: > On 27 January 2017 at 03:53, Robert Haas wrote: >> Sorry, this had slipped through the cracks -- I'm having a very hard >> time keeping up with the flow of patches and emails. But it looks >> good to me, except that it seems

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

2017-01-29 Thread David Rowley
On 27 January 2017 at 03:53, Robert Haas wrote: > Sorry, this had slipped through the cracks -- I'm having a very hard > time keeping up with the flow of patches and emails. But it looks > good to me, except that it seems like CountDBBackends() needs the same > fix (and

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

2017-01-26 Thread Robert Haas
On Thu, Jan 26, 2017 at 7:59 AM, David Rowley wrote: > On 12 January 2017 at 15:24, David Rowley > wrote: >> I've attached a patch which intended to assist discussions on this topic. >> >> The patch adds some notes to the docs to

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

2017-01-26 Thread David Rowley
On 12 January 2017 at 15:24, David Rowley wrote: > 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 >

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

2017-01-11 Thread David Rowley
> On 12 January 2017 at 09:36, Robert Haas 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

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

2017-01-11 Thread David Rowley
On 12 January 2017 at 09:36, Robert Haas 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

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

2017-01-11 Thread Robert Haas
On Tue, Jan 10, 2017 at 4:14 PM, David Rowley wrote: > It has come to my attention that when a user has a CONNECTION LIMIT > set, and they make use of parallel query, that their queries can fail > due to the connection limit being exceeded. That's bad. > Now, as I

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

2017-01-11 Thread Albe Laurenz
Amit Kapila wrote: > On Wed, Jan 11, 2017 at 2:44 AM, David Rowley > wrote: >> It has come to my attention that when a user has a CONNECTION LIMIT >> set, and they make use of parallel query, that their queries can fail >> due to the connection limit being exceeded.

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

2017-01-10 Thread Amit Kapila
On Wed, Jan 11, 2017 at 2:44 AM, David Rowley wrote: > It has come to my attention that when a user has a CONNECTION LIMIT > set, and they make use of parallel query, that their queries can fail > due to the connection limit being exceeded. > > Simple test case: > >

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

2017-01-10 Thread David Rowley
It has come to my attention that when a user has a CONNECTION LIMIT set, and they make use of parallel query, that their queries can fail due to the connection limit being exceeded. Simple test case: postgres=# CREATE USER user1 LOGIN CONNECTION LIMIT 2; CREATE ROLE postgres=# \c postgres user1