Re: [PROPOSAL] Client Log Output Filtering

On 3/28/16 2:00 PM, Tom Lane wrote:

> I set to work on committing this, but was soon rather dissatisfied with
> it, because as-implemented there is no way to short-circuit elog.c's
> processing if the message is not to be sent to either the client or the
> postmaster log.  Ideally this would be taken into account when errstart()
> figures the output_to_client setting to begin with --- but of course we
> can't do that with this API, because errhidefromclient() hasn't run yet.

That's a weakness of this approach but I'm not sure it's a big deal 
since there will generally still be output on the server.  If both are 
suppressed I think that would be a sign of misconfiguration.

> The patch is buggy even without that consideration, because it would
> potentially disable client output of messages even after they've been
> promoted to FATAL by pg_re_throw.  We could fix that by clearing the flag
> in pg_re_throw, but I think that's just another symptom of the shutoff
> being done in the wrong place.

Or elevel could be checked in EmitErrorReport():
if (edata->output_to_client &&            !(edata->hide_from_client && edata->elevel < ERROR))
send_message_to_frontend(edata);

> I wonder just what the expected usage scenario is for this function, and
> whether it would not be better addressed by inventing some other API
> rather than modeling it on errhidestmt(), which is by no means the same
> kind of thing.

The particular use case I have in mind is to suppress client output in 
pgaudit.  The original patch took a different approach by trying to 
merge with the logic to suppress messages in auth.  Maybe you should 
take a look at that patch and see what you think:

http://www.postgresql.org/message-id/5655B621.3080906@pgmasters.net

> One idea is to invent a new elevel which is never sent to the client ---
> analogously to COMMERROR, though probably much higher priority than that,
> maybe the same priority as LOG.  If there actually is a use for a range of
> elevels on errhidefromclient'd messages, that wouldn't work very well of
> course.  Or we could consider having a flag bit that is OR'd into the
> elevel <...>

I think a flag would be more flexible than introducing a new log level.

-- 
-David
david@pgmasters.net