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
--
Karel Zak <[EMAIL PROTECTED]>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
