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(at)pgmasters(dot)net