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 can be configured
differently for d
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 session
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 wor
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 "CONNECTION LIMIT". I'd
>> assume any CONNE
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
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 w
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 like CountDBBackends() n
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 probably a corresponding d
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 mention that background
>> workers and prepared xacts are not coun
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
> then goes on and makes CountUserB
> 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 started is a backgr
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 started is a background w
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 understand it, during the desig
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.
>>
>> Simple test case:
>>
>> p
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:
>
> postgres=# CREATE USER user1 LO
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
Y
16 matches
Mail list logo
