Prevent remote libpq notices from being sent to clients

On Fri, Jun 5, 2026 at 6:32 PM Chao Li <li.evan.chao@gmail.com> wrote:

So remote messages should only be output to the server log, but currently they can leak to the client if client_min_messages is set to log.

I'm not sure whether it's good idea to add this limitation.

I just thought that some users might find it useful to send log messages
containing remote messages to the client when needed. For example,
in the following case, at least for me it seems helpful to see the LOG
message including the remote message:

=# SELECT * FROM dblink_exec(..., 'create table if not exists t(i int)');
LOG: received message via remote connection: NOTICE: relation
"t" already exists, skipping

So I'd like to hear more opinions from others. If the consensus is that
remote messages should never be sent to the client, I'm fine with
adding the limitation.

Regards,

--
Fujii Masao

Fujii Masao <masao.fujii@gmail.com> writes:

On Fri, Jun 5, 2026 at 6:32 PM Chao Li <li.evan.chao@gmail.com> wrote:

So remote messages should only be output to the server log, but currently they can leak to the client if client_min_messages is set to log.

I'm not sure whether it's good idea to add this limitation.

I was just about to answer saying that I didn't think so. I'm
concerned that there might be no other way to obtain such output.
It's likely that the remote server doesn't log NOTICE-level messages,
and even if it does, you might not have access to its log.

Also, I don't buy the argument that this is a "leak": if the remote
server was willing to send the message to its client, it doesn't think
that the message is security-critical.

What I think there might be a good case for is to use the same ereport
level that was used to issue the remote's message, rather than always
LOG level. I'm not sure if we can reconstruct that completely, but we
can certainly tell NOTICE from WARNING, for instance.

regards, tom lane

On Fri, Jun 5, 2026 at 7:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, I don't buy the argument that this is a "leak": if the remote
server was willing to send the message to its client, it doesn't think
that the message is security-critical.

I don't think the remote gets to decide that, in general. It's up to
the middle layer to know whether it's operating at the same level of
trust as the end client.

--Jacob

On Fri Jun 5, 2026 at 9:32 AM UTC, Chao Li wrote:

Hi,

This is another issue with “[112faf137] Log remote NOTICE, WARNING, and similar messages using ereport()”. From the commit message, the intention of the feature is to log remote messages with ereport() to get better formatting:
```
Log remote NOTICE, WARNING, and similar messages using ereport().

Previously, NOTICE, WARNING, and similar messages received from remote
servers over replication, postgres_fdw, or dblink connections were printed
directly to stderr on the local server (e.g., the subscriber). As a result,
these messages lacked log prefixes (e.g., timestamp), making them harder
to trace and correlate with other log entries.

This commit addresses the issue by introducing a custom notice receiver
for replication, postgres_fdw, and dblink connections. These messages
are now logged via ereport(), ensuring they appear in the logs with proper
formatting and context, which improves clarity and aids in debugging.
```

So remote messages should only be output to the server log, but currently they can leak to the client if client_min_messages is set to log.

This is a simple repro:
```
evantest=# set client_min_messages=log;
SET
evantest=# select * from dblink('host=localhost dbname=postgres’,
'do $$ begin raise warning ''hello, client!!!''; end $$; select 1’)
as t(x int);
LOG: received message via remote connection: WARNING: hello, client!!!
x
---
1
(1 row)
```

The one-line fix is straightforward, just change the ereport() level from LOG to LOG_SERVER_ONLY. I also added a test in the patch.

This looks good to me. Do you think we should also copy the test to
postgres_fdw? Or, I wonder if there is an even better location for the
test outside of either's regression suite.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)

On Jun 5, 2026, at 23:20, Jacob Champion <jacob.champion@enterprisedb.com> wrote:

On Fri, Jun 5, 2026 at 7:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Also, I don't buy the argument that this is a "leak": if the remote
server was willing to send the message to its client, it doesn't think
that the message is security-critical.

I don't think the remote gets to decide that, in general. It's up to
the middle layer to know whether it's operating at the same level of
trust as the end client.

--Jacob

Thanks to all for the input. It looks like people have different opinions on this topic. BTW, I realized that my previous wording of "leak" was too strong, sorry about that.

Here, I think the main concern is that this is an “unintentional" user-visible behavior change. I went through the original discussion thread [1]/messages/by-id/CALDaNm2xsHpWRtLm-VL_HJCsaE3+1Y_n-jDEAr3-suxVqc3xoQ@mail.gmail.com, and I don't see this behavior change being explicitly discussed. I am not against Fujii's idea that emitting a remote WARNING to the client could be helpful, and I also like Tom's idea of mapping the remote severity to the local log level. But if we really want to do that, I think we need a dedicated discussion, and that seems too late for v19. Also, if we eventually decide to change the client-visible behavior, I think we should document it explicitly.

How about preserving the old client-visible behavior for v19? I can add this topic to my TODO list and follow up with this work for v20.

[1]: /messages/by-id/CALDaNm2xsHpWRtLm-VL_HJCsaE3+1Y_n-jDEAr3-suxVqc3xoQ@mail.gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/