Re: [PROPOSAL] Client Log Output Filtering
От | David Steele |
---|---|
Тема | Re: [PROPOSAL] Client Log Output Filtering |
Дата | |
Msg-id | 569868C4.9080003@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Client Log Output Filtering (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [PROPOSAL] Client Log Output Filtering
|
Список | 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 по дате отправления: