From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PROPOSAL] Client Log Output Filtering |
Date: | 2016-01-15 03:34:28 |
Message-ID: | 569868C4.9080003@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2016-01-15 03:36:12 | Re: Optimization for updating foreign tables in Postgres FDW |
Previous Message | Robert Haas | 2016-01-15 03:02:39 | Re: [PROPOSAL] Client Log Output Filtering |