Re: I am done - Mailing list pgsql-hackers

From Tom Lane
Subject Re: I am done
Date
Msg-id 28520.1031231561@sss.pgh.pa.us
Whole thread Raw
In response to Re: I am done  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: I am done  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: I am done  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: I am done  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> Since the flawed code is now in beta, it will need to be fixed. Do people
> like the above solution or should I just revert to having a seperate
> function for each GUC variable affected?

I do not see a good reason why "fatal" and "off" shouldn't be allowed
values for all three message variables.  If we just did that, then you'd
be back to sharable code.

BTW, is it a good idea for server_min_messages and
log_min_error_statement to be PGC_USERSET?  I could see an argument that
they should be PGC_SIGHUP, ie, settable only by the admin.  As it is,
any user can hide his activity from the logs.  OTOH, in the past we've
allowed anyone to change the debug level, and there haven't been
complaints about it.

There's some value in being able to kick the log level up a notch for
a specific session, but knocking it down from the admin's default could
be considered a bad thing.  I suppose we could invent a PGC_SIGHUP
"min_server_min_messages" variable that sets a minimum value below which
the user can't set server_min_messages.  Does that seem like a good
idea, or overkill?

A compromise position would be to make these two variables PG_SUSET,
ie settable per-session but only if you're superuser.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Inheritance
Next
From: Tom Lane
Date:
Subject: Re: TODO item on triggers