Re: [PROPOSAL] Client Log Output Filtering

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [PROPOSAL] Client Log Output Filtering
Дата
Msg-id 20160111235046.GA798998@alvherre.pgsql
обсуждение исходный текст
Ответ на [PROPOSAL] Client Log Output Filtering  (David Steele <david@pgmasters.net>)
Ответы Re: [PROPOSAL] Client Log Output Filtering  (Robert Haas <robertmhaas@gmail.com>)
Re: [PROPOSAL] Client Log Output Filtering  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
David Steele wrote:
> Currently log messages generated by pgaudit can be made visible to the
> client simply by altering client_min_messages.  While this has not been a
> showstopper for anyone it's ideal, either.
> 
> The client authentication code sets the global variable ClientAuthInProgress
> which causes ereport() to filter client output < ERROR while forcing client
> output >= ERROR.  This functionality would also work well for pgaudit.
> 
> The patch creates a new counter to separate the log filtering from the
> authentication functionality.  This makes it possible to get the same
> filtering in other parts of the code (or extensions) without abusing the
> ClientAuthInProgress variable or using the log hook.

Hmm, okay, but this would need a large blinking comment explaining that
the calling code have better set a PG_TRY block when incrementing, so
that on errors it resets to zero again.  Or maybe some handling in
AbortOutOfAnyTransaction/AbortCurrentTransaction.  or both.

> I also considered a new function for ereport (like errhidecontext()) but
> this mechanism would not have worked for authentication and so would not
> have been used anywhere in core.

But then, you already know that authentication phase is not exactly the
same use case as security auditing, so they don't have to work the same
way necessarily.  I think this needs more discussion.  If the audit code
calls something that throws an error (other than an audit message -- say
"out of memory"), then it would also be hidden, but you may not want it
to be hidden.  I think maybe it's better to have each individual error
message be marked as "don't show to client" rather than a global var.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Making plpython 2 and 3 coexist a bit better
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fuzzy substring searching with the pg_trgm extension