Skip site navigation (1) Skip section navigation (2)

Re: per user/database connections limit again

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Petr Jelinek <pjmodos(at)parba(dot)cz>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: per user/database connections limit again
Date: 2005-07-28 22:11:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
I have "worked over" your patch and I think it is ready for application.

I changed the syntax to CONNECTION LIMIT, which seems most natural.  We
could skip CONNECTION and just use a LIMIT keyword, but that seems too

I removed your use of the pg_auth flat file.  By the time you have the
PROC entry to do your lookups, you might as well just use the system

There is a race condition in the code because we set our PROC entry
before we check for other entries.  If there is one connection left and
two backends do this at the same time, they would both fail, while one
should fail and the other succeed. Without a lock, I see no way to avoid
it so I just commented it in the code.

Also, I felt that zero should mean allow no/zero connections, rather
than representing unlimited connections.  I used -1 for unlimited.  We
can either document the use of -1, or add syntax to allow NO CONNECTION
LIMIT, or something like that.

The patch requires a catalog version update when applied.


Petr Jelinek wrote:
> Stephen Frost wrote:
> >This should almost certainly be a pg_database_ownercheck() call instead.
> >  
> >
> Right there wasn't pg_database_ownercheck at the time I was writing it, 
> fixed
> >The rest needs to be updated for roles, but looks like it should be 
> >pretty easy to do.  Much of it just needs to be repatched, the parts 
> >that do need to be changed look to be pretty simple changes.
> >  
> >
> Done.
> >I believe the use of SessionUserId is probably correct in this patch.
> >This does mean that this patch will only be for canlogin roles, but that
> >seems like it's probably correct.  Handling roles w/ members would
> >require much more thought.
> >  
> >
> I don't think that having max connection for roles w/ members is doable 
> because you can have 5 roles which has 1 user as member and each role 
> has different number of max conections and there is no right way to 
> decide what to do.
> New version which works with roles is attached (diffed against cvs), 
> everything else is mostly same.
> I also had to readd roleid to flatfiles because I need it in 
> InitProcess() function.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-07-28 22:14:03
Subject: Re: psql tab-completion for COMMIT/ROLLBACK PREPARED
Previous:From: Magnus HaganderDate: 2005-07-28 20:26:31
Subject: Win32 eventlog level fix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group