Re: [PROPOSAL] Client Log Output Filtering - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [PROPOSAL] Client Log Output Filtering
Date
Msg-id 20160111235046.GA798998@alvherre.pgsql
Whole thread Raw
In response to [PROPOSAL] Client Log Output Filtering  (David Steele <david@pgmasters.net>)
Responses Re: [PROPOSAL] Client Log Output Filtering  (Robert Haas <robertmhaas@gmail.com>)
Re: [PROPOSAL] Client Log Output Filtering  (David Steele <david@pgmasters.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Making plpython 2 and 3 coexist a bit better
Next
From: Tom Lane
Date:
Subject: Re: Fuzzy substring searching with the pg_trgm extension