Re: A modest proposal: get rid of GUC's USERLIMIT variable - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: A modest proposal: get rid of GUC's USERLIMIT variable
Date
Msg-id 200411100524.iAA5Ojt10045@candle.pha.pa.us
Whole thread Raw
In response to Re: A modest proposal: get rid of GUC's USERLIMIT variable category  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> 
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > I'd like to propose that we get rid of GUC's USERLIMIT category and
> > convert all the variables in it to plain SUSET.  In my mind, USERLIMIT
> > is a failed experiment: it's way too complicated, and it still doesn't
> > do quite what it was intended to do, because there are times when it
> > can't check whether you're a superuser.
> > 
> > The only variables that are in the category are log-verbosity-related:
> 
> Would that mean I wouldn't be able to change the logging level on the fly at
> all?
> 
> That would disappoint at least one user, myself. I've found the best debugging
> compromise is to leave log_statement off in general but have a magic parameter
> I can pass to the application that will set log_statement = true for a single
> transaction.
> 
> That way I can look at what queries transpired in my session without having to
> dig through hundreds of other queries from other sessions. And have the
> complete logs for the session I'm debugging without the performance impact in
> the normal case.

Yes, this would not be possible for non-super users with the new
proposal.  You could set the setting for non-super users per-user but
not per-session.

--  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: Greg Stark
Date:
Subject: Re: A modest proposal: get rid of GUC's USERLIMIT variable category
Next
From: Oleg Bartunov
Date:
Subject: Re: sp-gist porting to postgreSQL