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: pgsql-patches(at)postgresql(dot)org
Subject: Re: per user/database connections limit again
Date: 2005-07-29 12:49:36
Message-ID: 200507291249.j6TCnag12502@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Petr Jelinek wrote:
> Bruce Momjian wrote:
> 
> >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
> >cache.
> >
> >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.
> >  
> >
> Yeah my working version was doing this too but I wanted to avoid lock on 
> PROC array and that race condition and because pg_auth is loaded anyway 
> I used it.

Well, we are locking the PROC array for the db scan as well, so I don't
see a difference for user.  Also, I don't see how it would avoid the
race condition.  We could scan PROC and then set our user value, but
that would allow possibly too many connections rather than too few.

> >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.
> >  
> >
> Right, maybe we could remove datallowconn from pg_database (in future) 
> if we can achieve same thing using datconnlimit = 0 ?

Yes, we certainly could, but I am betting we would need both because if
someone wanted to close down a database, _but_ keep the existing limit
so it could be resetored later, they would still use datallowconn.

> >The patch requires a catalog version update when applied.
> >  
> >
> Yes, thanks for your work on this patch, I will write documentation for 
> it in next few days.

Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-07-29 12:59:51
Subject: Re: small SPI docs correction
Previous:From: Bruce MomjianDate: 2005-07-29 12:37:00
Subject: Re: [PATCHES] COPY FROM performance improvements

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