Re: [PROPOSAL] Client Log Output Filtering

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

In response to

Responses

Browse pgsql-hackers by date

  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