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

Re: idle connection timeout ...

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Andrew Sullivan <andrew(at)libertyrms(dot)info>,PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: idle connection timeout ...
Date: 2002-10-29 07:11:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Oct 25, 2002 at 03:31:22PM -0400, 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.

 Yes! Please.... it's better than all discussions about some ugly
 variables. The PROFILE is better extendable and it's user 
 specific and in the system with ROLEs it really cool and simple
 set user's system options.
 I talked about it more times, but is still ignore :-) I don't want 
 to maintain my databases by SET command.

> profname
> session_per_user
> cpu_per_session
> cpu_per_call
> connect_time
> idle_time
> logical_reads_per_session
> logical_reads_per_call

 ... and a lot of others things in future.


 Karel Zak  <zakkr(at)zf(dot)jcu(dot)cz>
 C, PostgreSQL, PHP, WWW,,

In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2002-10-29 08:21:17
Subject: Re: Request for supported platforms
Previous:From: Bruce MomjianDate: 2002-10-29 04:24:01
Subject: Re: Request for supported platforms

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