Thank you for looking over this. New version attached.

On Tue, Feb 17, 2026 at 2:58 PM Andres Freund <[email protected]> wrote:

> What about direct TLS connections?


Not handled.

How can a cluster coordinator trust unauthenticated plain text
> communication that can just be man-in-the-middled?
>

They cannot. But that's why this is only exposing non-critical information.
Right now the security scanners that are banging on port 5432 and scraping
the returned error lines are not worried about man-in-the-middle. :)
Obviously, if your threat model is people capturing and modifying
non-encrypted traffic to your Postgres server, you would not use this.

It's not obvious that it's a good idea to expose this on the same socket as
> normal client connections.  IMO you'd want to limit this to a smaller set
> of interfaces than normal client connections.
>

I'm not entirely clear what that smaller set would mean in practice.


> IIRC the socket is in blocking mode at this point (that's only changed in
> pq_init()), therefore this might actually block?  While it's unlikely, I
> don't see any guarantee that a single receive would actually get the whole
> message from the client either, so this seems like it might fail spuriously.
>

Yes, there are some very unlikely edge cases, but this is meant to be good
enough, not a perfectly bulletproof HTTP server. Clients should try again
on failures. Which if they do occur for this trivial amount of traffic
probably indicates much bigger problems.

If we were to do this, I'd recommend a single expose GUC that has the
> different values as a comma separated list, instead a growing list of GUCs.
>

Done - see attached for a new version which consolidates the bools into a
single comma-separated GUC called "expose_information". I also added some
docs, and changed the "replica" to return "REPLICA" instead of "RECOVERY".
I like the latter better, but replica lines up better with existing tools.

-- 
Cheers,
Greg

Attachment: 0006-Allow-specific-information-to-be-output-directly-by-Postgres.patch
Description: Binary data

Reply via email to