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.3080...@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
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
