| From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mike Mascari <mascarm(at)mascari(dot)com>, 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-25 20:32:58 |
| Message-ID: | 1035577978.12583.90.camel@camel |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2002-10-25 at 16:17, Tom Lane wrote:
> Mike Mascari <mascarm(at)mascari(dot)com> writes:
> > [ extensive proposal for PROFILEs ]
> > It seems like a nice project, particularly since it wouldn't
> > affect anyone that doesn't want to use it.
>
> ... except in the added overhead to do the resource accounting and check
> to see if there is a restriction ...
perhaps you could make a GUC variable "use_resource_profiles" that turns
the whole thing on/off.
>
> > 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...
>
> I prefer GUC variables to table entries for setting stuff like recursion
> limits; they're much lighter-weight to create and access, and you don't
> need an initdb to add or remove a parameter.
>
I don't see an adequate way to store the individual settings as GUC
variables per user...
Robert Treat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-10-25 20:43:41 | Re: idle connection timeout ... |
| Previous Message | Bruce Momjian | 2002-10-25 20:18:22 | Time for RC1 soon? |