diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-11-08 17:33:25 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-11-08 17:33:43 -0500 |
commit | 3d360e20c9ae48a8139b4dd84f5a8bacc392d8e9 (patch) | |
tree | 8292e5f04cc254d7ef1c38d28bcd6c3857d74833 /src/backend/utils/error/elog.c | |
parent | 705d433fd5e29ac173ef46a5acd4a2d7336f5573 (diff) | |
download | postgresql-3d360e20c9ae48a8139b4dd84f5a8bacc392d8e9.tar.gz postgresql-3d360e20c9ae48a8139b4dd84f5a8bacc392d8e9.zip |
Disallow setting client_min_messages higher than ERROR.
Previously it was possible to set client_min_messages to FATAL or PANIC,
which had the effect of suppressing transmission of regular ERROR messages
to the client. Perhaps that seemed like a useful option in the past, but
the trouble with it is that it breaks guarantees that are explicitly made
in our FE/BE protocol spec about how a query cycle can end. While libpq
and psql manage to cope with the omission, that's mostly because they
are not very bright; client libraries that have more semantic knowledge
are likely to get confused. Notably, pgODBC doesn't behave very sanely.
Let's fix this by getting rid of the ability to set client_min_messages
above ERROR.
In HEAD, just remove the FATAL and PANIC options from the set of allowed
enum values for client_min_messages. (This change also affects
trace_recovery_messages, but that's OK since these aren't useful values
for that variable either.)
In the back branches, there was concern that rejecting these values might
break applications that are explicitly setting things that way. I'm
pretty skeptical of that argument, but accommodate it by accepting these
values and then internally setting the variable to ERROR anyway.
In all branches, this allows a couple of tiny simplifications in the
logic in elog.c, so do that.
Also respond to the point that was made that client_min_messages has
exactly nothing to do with the server's logging behavior, and therefore
does not belong in the "When To Log" subsection of the documentation.
The "Statement Behavior" subsection is a better match, so move it there.
Jonah Harris and Tom Lane
Discussion: https://postgr.es/m/7809.1541521180@sss.pgh.pa.us
Discussion: https://postgr.es/m/15479-ef0f4cc2fd995ca2@postgresql.org
Diffstat (limited to 'src/backend/utils/error/elog.c')
-rw-r--r-- | src/backend/utils/error/elog.c | 11 |
1 files changed, 2 insertions, 9 deletions
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c index b9c11301ca2..ca02aac4ebd 100644 --- a/src/backend/utils/error/elog.c +++ b/src/backend/utils/error/elog.c @@ -469,9 +469,7 @@ errfinish(int dummy,...) * progress, so that we can report the message before dying. (Without * this, pq_putmessage will refuse to send the message at all, which is * what we want for NOTICE messages, but not for fatal exits.) This hack - * is necessary because of poor design of old-style copy protocol. Note - * we must do this even if client is fool enough to have set - * client_min_messages above FATAL, so don't look at output_to_client. + * is necessary because of poor design of old-style copy protocol. */ if (elevel >= FATAL && whereToSendOutput == DestRemote) pq_endcopyout(true); @@ -1747,12 +1745,7 @@ pg_re_throw(void) else edata->output_to_server = (FATAL >= log_min_messages); if (whereToSendOutput == DestRemote) - { - if (ClientAuthInProgress) - edata->output_to_client = true; - else - edata->output_to_client = (FATAL >= client_min_messages); - } + edata->output_to_client = true; /* * We can use errfinish() for the rest, but we don't want it to call |