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

From Greg Stark
Subject Re: A modest proposal: get rid of GUC's USERLIMIT variable category
Date
Msg-id 87mzxqgu0x.fsf@stark.xeocode.com
Whole thread Raw
In response to A modest proposal: get rid of GUC's USERLIMIT variable category  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A modest proposal: get rid of GUC's USERLIMIT variable  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: A modest proposal: get rid of GUC's USERLIMIT variable  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: A modest proposal: get rid of GUC's USERLIMIT variable category  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

-- 
greg



pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [Pgsphere-dev] GIST index concurrency concern
Next
From: Bruce Momjian
Date:
Subject: Re: A modest proposal: get rid of GUC's USERLIMIT variable