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

From David Steele
Subject Re: [PROPOSAL] Client Log Output Filtering
Date
Msg-id 569868C4.9080003@pgmasters.net
Whole thread Raw
In response to Re: [PROPOSAL] Client Log Output Filtering  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PROPOSAL] Client Log Output Filtering  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 1/11/16 6:50 PM, Alvaro Herrera wrote:
> David Steele wrote:
>> 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.

In the case of pgaudit only the ereport call is wrapped in the 
LimitClientLogOutput() calls which I thought was safe - am I wrong about 
that?

>> 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.

> 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.

This shouldn't happen -- see above.

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.

That's easy enough to do and I already have the code for it since that's 
the first thing I tried.  However, there were two reasons I didn't 
submit that version:

1) Unless pgaudit is committed there wouldn't be any code calling the 
errhidefromclient() function and that seemed like a bad plan.

2) There would be two different ways to suppress client messages but I 
was hoping to only have one.

As you say, authentication is a different beast so maybe #2 is not a big 
deal.  I could combine the alternative ereport patch with the pgaudit 
patch to address #1 but I would like to have the capability in core 
whether pgaudit is committed or not, which is why I submitted it separately.

Any advice would be greatly appreciated.

Thanks,
-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] Client Log Output Filtering
Next
From: Etsuro Fujita
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW