Re: [PROPOSAL] Client Log Output Filtering

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Client Log Output Filtering
Date: 2016-01-11 23:50:46
Message-ID: 20160111235046.GA798998@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-01-11 23:57:51 Re: Fuzzy substring searching with the pg_trgm extension
Previous Message Tom Lane 2016-01-11 23:33:19 Re: Making plpython 2 and 3 coexist a bit better