public inbox for [email protected]
help / color / mirror / Atom feedPrevent remote libpq notices from being sent to clients
6+ messages / 5 participants
[nested] [flat]
* Prevent remote libpq notices from being sent to clients
@ 2026-06-05 09:31 Chao Li <[email protected]>
2026-06-05 14:28 ` Re: Prevent remote libpq notices from being sent to clients Fujii Masao <[email protected]>
2026-06-05 20:34 ` Re: Prevent remote libpq notices from being sent to clients Tristan Partin <[email protected]>
0 siblings, 2 replies; 6+ messages in thread
From: Chao Li @ 2026-06-05 09:31 UTC (permalink / raw)
To: Postgres hackers <[email protected]>; +Cc: Fujii Masao <[email protected]>; vignesh C <[email protected]>
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.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
[application/octet-stream] v1-0001-Avoid-sending-remote-libpq-notices-back-to-client.patch (3.0K, 2-v1-0001-Avoid-sending-remote-libpq-notices-back-to-client.patch)
download | inline diff:
From be744e8ca867626f721ad146214cde9db395834e Mon Sep 17 00:00:00 2001
From: "Chao Li (Evan)" <[email protected]>
Date: Fri, 5 Jun 2026 17:18:11 +0800
Subject: [PATCH v1] Avoid sending remote libpq notices back to clients
Commit 112faf137 added a custom libpq notice receiver so that remote
NOTICE, WARNING, and similar messages from dblink, postgres_fdw, and
replication connections are logged via ereport(). The receiver used LOG,
which preserves server logging, but LOG can also be sent to the local SQL
client when client_min_messages is set to log.
That exposes remote notices to the client as local LOG messages, unlike the
previous libpq default notice processor behavior, which printed them only to
backend stderr.
Use LOG_SERVER_ONLY instead. This keeps the messages in the server log while
preventing them from being sent to the SQL client. Add a dblink regression
test for the client-visible case.
Author: Chao Li <[email protected]>
---
contrib/dblink/expected/dblink.out | 12 ++++++++++++
contrib/dblink/sql/dblink.sql | 8 ++++++++
src/include/libpq/libpq-be-fe-helpers.h | 2 +-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index 1d2759def9e..835367b3668 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -176,6 +176,18 @@ WHERE t.a > 7;
9 | j | {a9,b9,c9}
(2 rows)
+-- remote notices should be logged server-side only
+SET client_min_messages = log;
+SELECT *
+FROM dblink(connection_parameters(),
+ $$DO $do$ BEGIN RAISE NOTICE 'remote notice'; END $do$; SELECT 1$$)
+ AS t(x int);
+ x
+---
+ 1
+(1 row)
+
+RESET client_min_messages;
-- should generate "connection not available" error
SELECT *
FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
diff --git a/contrib/dblink/sql/dblink.sql b/contrib/dblink/sql/dblink.sql
index d67a0a5992e..4c043a3ef87 100644
--- a/contrib/dblink/sql/dblink.sql
+++ b/contrib/dblink/sql/dblink.sql
@@ -128,6 +128,14 @@ SELECT *
FROM dblink(connection_parameters(),'SELECT * FROM foo') AS t(a int, b text, c text[])
WHERE t.a > 7;
+-- remote notices should be logged server-side only
+SET client_min_messages = log;
+SELECT *
+FROM dblink(connection_parameters(),
+ $$DO $do$ BEGIN RAISE NOTICE 'remote notice'; END $do$; SELECT 1$$)
+ AS t(x int);
+RESET client_min_messages;
+
-- should generate "connection not available" error
SELECT *
FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
diff --git a/src/include/libpq/libpq-be-fe-helpers.h b/src/include/libpq/libpq-be-fe-helpers.h
index cff68cd1c37..05b15118284 100644
--- a/src/include/libpq/libpq-be-fe-helpers.h
+++ b/src/include/libpq/libpq-be-fe-helpers.h
@@ -498,7 +498,7 @@ libpqsrv_notice_receiver(void *arg, const PGresult *res)
if (len > 0 && message[len - 1] == '\n')
len--;
- ereport(LOG,
+ ereport(LOG_SERVER_ONLY,
errmsg_internal("%s: %.*s", prefix, len, message));
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Prevent remote libpq notices from being sent to clients
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
@ 2026-06-05 14:28 ` Fujii Masao <[email protected]>
2026-06-05 14:43 ` Re: Prevent remote libpq notices from being sent to clients Tom Lane <[email protected]>
1 sibling, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2026-06-05 14:28 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: Postgres hackers <[email protected]>; vignesh C <[email protected]>
On Fri, Jun 5, 2026 at 6:32 PM Chao Li <[email protected]> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Prevent remote libpq notices from being sent to clients
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
2026-06-05 14:28 ` Re: Prevent remote libpq notices from being sent to clients Fujii Masao <[email protected]>
@ 2026-06-05 14:43 ` Tom Lane <[email protected]>
2026-06-05 15:20 ` Re: Prevent remote libpq notices from being sent to clients Jacob Champion <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2026-06-05 14:43 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Chao Li <[email protected]>; Postgres hackers <[email protected]>; vignesh C <[email protected]>
Fujii Masao <[email protected]> writes:
> On Fri, Jun 5, 2026 at 6:32 PM Chao Li <[email protected]> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Prevent remote libpq notices from being sent to clients
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
2026-06-05 14:28 ` Re: Prevent remote libpq notices from being sent to clients Fujii Masao <[email protected]>
2026-06-05 14:43 ` Re: Prevent remote libpq notices from being sent to clients Tom Lane <[email protected]>
@ 2026-06-05 15:20 ` Jacob Champion <[email protected]>
2026-06-06 01:10 ` Re: Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Jacob Champion @ 2026-06-05 15:20 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Fujii Masao <[email protected]>; Chao Li <[email protected]>; Postgres hackers <[email protected]>; vignesh C <[email protected]>
On Fri, Jun 5, 2026 at 7:43 AM Tom Lane <[email protected]> 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Prevent remote libpq notices from being sent to clients
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
2026-06-05 14:28 ` Re: Prevent remote libpq notices from being sent to clients Fujii Masao <[email protected]>
2026-06-05 14:43 ` Re: Prevent remote libpq notices from being sent to clients Tom Lane <[email protected]>
2026-06-05 15:20 ` Re: Prevent remote libpq notices from being sent to clients Jacob Champion <[email protected]>
@ 2026-06-06 01:10 ` Chao Li <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Chao Li @ 2026-06-06 01:10 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Tom Lane <[email protected]>; Fujii Masao <[email protected]>; Postgres hackers <[email protected]>; vignesh C <[email protected]>
> On Jun 5, 2026, at 23:20, Jacob Champion <[email protected]> wrote:
>
> On Fri, Jun 5, 2026 at 7:43 AM Tom Lane <[email protected]> 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], 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] https://postgr.es/m/CALDaNm2xsHpWRtLm-VL_HJCsaE3+1Y_n-jDEAr3-suxVqc3xoQ@mail.gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Prevent remote libpq notices from being sent to clients
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
@ 2026-06-05 20:34 ` Tristan Partin <[email protected]>
1 sibling, 0 replies; 6+ messages in thread
From: Tristan Partin @ 2026-06-05 20:34 UTC (permalink / raw)
To: Chao Li <[email protected]>; +Cc: Fujii Masao <[email protected]>; vignesh C <[email protected]>; Postgres hackers <[email protected]>
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)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-06-06 01:10 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-05 09:31 Prevent remote libpq notices from being sent to clients Chao Li <[email protected]>
2026-06-05 14:28 ` Fujii Masao <[email protected]>
2026-06-05 14:43 ` Tom Lane <[email protected]>
2026-06-05 15:20 ` Jacob Champion <[email protected]>
2026-06-06 01:10 ` Chao Li <[email protected]>
2026-06-05 20:34 ` Tristan Partin <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox