Re: idle connection timeout ... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: idle connection timeout ...
Date
Msg-id 200210251954.g9PJsRH29140@candle.pha.pa.us
Whole thread Raw
In response to Re: idle connection timeout ...  (Mike Mascari <mascarm@mascari.com>)
Responses Re: idle connection timeout ...
List pgsql-hackers
I need others wanting this before I can add something of this
sophistication to TODO.

---------------------------------------------------------------------------

Mike Mascari wrote:
> Bruce Momjian wrote:
> > Andrew Sullivan wrote:
> > 
> >>On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote:
> >>
> >>>So?  If it hits the installation-wide limit, you'll have the same
> >>>problem; and at that point the (presumably runaway) app would have
> >>>sucked up all the connections, denying service to other apps using other
> >>>databases.  I think Marc's point here is to limit his exposure to
> >>>misbehavior of any one client app, in a database server that is serving
> >>>multiple clients using multiple databases.
> >>
> >>That would indeed be a useful item.  The only way to avoid such
> >>exposure right now is to run another back end.
> > 
> > 
> > Added to TODO:
> > 
> >     * Allow limits on per-db/user connections
> > 
> 
> Could I suggest that such a feature falls under the category of 
> resource limits, and that the TODO should read something like:
> 
> Implement the equivalent of Oracle PROFILEs.
> 
> I think this would be a good project for 7.4. I'm not yet 
> volunteering, but if I can wrap up my current project, I might 
> be able to do it, depending upon the 7.4 target date. It would be:
> 
> 1. A new system table:
> 
> pg_profile
> 
> 2. The attributes of the profiles would be:
> 
> profname
> session_per_user
> cpu_per_session
> cpu_per_call
> connect_time
> idle_time
> logical_reads_per_session
> logical_reads_per_call
> 
> 3. A new field would be added to pg_user/pg_shadow:
> 
> profileid
> 
> 4. A 'default' profile would be created when a new database is 
> created with no resource limits. CREATE/ALTER user would be 
> modified to allow for the specification of the profile. If no 
> profile is provided, 'default' is assumed.
> 
> 5. A new CREATE PROFILE/ALTER PROFILE/DROP PROFILE command set 
> would be implemented to add/update/remove the tuples in 
> pg_profiles. And according modification of pg_dump for 
> dump/reload and psql for appropriate \ command.
> 
> Example:
> 
> CREATE PROFILE clerk
> IDLE_TIME 30;
> 
> ALTER USER john PROFILE clerk;
> ALTER USER bob PROFILE clerk;
> 
> or, for an ISP maybe:
> 
> ALYTER PROFILE default
> IDLE_TIME 30;
> 
> It seems like a nice project, particularly since it wouldn't 
> affect anyone that doesn't want to use it. And whenever a new 
> resource limitation issue arrises, such as PL/SQL recursion 
> depth, a new attribute would be added to pg_profile to handle 
> the limitation...
> 
> Mike Mascari
> mascarm@mascari.com
> 
> 
> 
> 
> 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: idle connection timeout ...
Next
From: Tom Lane
Date:
Subject: Re: idle connection timeout ...