Re: I am done

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: I am done
Дата
Msg-id 28520.1031231561@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: I am done  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Inheritance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TODO item on triggers