Re: Prevent remote libpq notices from being sent to clients

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: Prevent remote libpq notices from being sent to clients
Date: 2026-06-05 14:43:16
Message-ID: 3592596.1780670596@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Fri, Jun 5, 2026 at 6:32 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laetitia Avrot 2026-06-05 15:16:21 Re: [Bug Report + Patch] File descriptor leak when io_method=io_uring
Previous Message zengman 2026-06-05 14:37:43 Re: (SQL/PGQ) cache lookup failed for label