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
da...@pgmasters.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to