|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||David Steele <david(at)pgmasters(dot)net>|
|Subject:||Re: [PROPOSAL] Client Log Output Filtering|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
David Steele wrote:
> 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
Yeah, errstart itself could fail. It's not common but it does happen.
> 1) Unless pgaudit is committed there wouldn't be any code calling the
> errhidefromclient() function and that seemed like a bad plan.
Well, you could add a test module to ensure it continues to work.
> 2) There would be two different ways to suppress client messages but I was
> hoping to only have one.
I think they are two different things actually.
I'm closing this as returned with feedback.
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Alvaro Herrera||2016-02-01 22:32:15||Re: checkpointer continuous flushing|
|Previous Message||Alvaro Herrera||2016-02-01 22:18:21||Re: snapshot too old, configured by time|