Re: contrib/pg_stat_tcpinfo

On 11/7/25 11:36, Jakub Wartak wrote:
> On Mon, Nov 3, 2025 at 3:09 PM Jakub Wartak
> <jakub.wartak@enterprisedb.com> wrote:
>>
>> Attached is pg_stat_tcpinfo, an heavy work in progress, Linux-only
>> netstat/ss-like extension for showing detailed information about TCP
>> connections based on information from the kernel itself.
> [..]
> 

I personally don't remember ever needing this kind of visibility into
TCP connections, but I'm also not doing all that much direct support
recently. And even in the past I personally didn't need to look at
TCP-level details all that much, the problems were usually elsewhere.

But maybe it's very useful in practice, don't know.

>> Some early feedback about direction in order to bring this into core
>> would be appreciated. State of stuff:
>>

Well, it's an extension in contrib. Is that sufficiently "in core"? Do
you expect this to be used in PROD environments, or more in DEV?

>> 1. Andres is pushing for supporting UNIX domain sockets here, but I'm
>> not sure if it is really worth the effort (and it would trigger new
>> naming problem;)) and primarily making the code even more complex.
>> IMHO the netlinksock_diag API is already convoluted and adding AF_UNIX
>> would make it even less readable.

No idea. For most real-world production systems the client is probably
on a different machine, so won't use UNIX sockets. Not always, but how
often do UNIX sockets have network-like problems for this visibility to
be helpful?

Also, how much work / extra code would it be to support UNIX sockets?

>> 2. IPv6 works, but wasn't tested much.
>> 3. Biggest TODO left is probably properly formatting the information
>> based on struct tcpinfo variables (just like ss(1) does, so keeping
>> the same unit/formatting)

I don't follow? Why do you want to format data the way "ss" does?

>> 4. Patch/tests are missing intentionally as I would like first to
>> stabilize the outputs/naming/code first.
>> 5. [security] Should this be available to pg_monitor/pg_read_all_stats
>> or just to superuser?

I suppose making this superuser-only would be against the effort to not
require superuser privileges, so using roles seems like the way to go.
The nature of the data seems very similar to pg_stat_activity (i.e. info
about current connections), so I'd suggest to use pg_read_all_stats. It
might even use an approach similar to pg_stat_get_activity(), which
shows some fields to everyone, and the role is required only for fields
with sensitive information.

>> 6. [security] Should this return info about all TCP connections or
>> just the UID of the postmaster?
> 

Not sure if I understand the question, but IMHO this should return only
info about connections opened by Postgres. Not for connections about TCP
connections opened by other stuff running on the server.


regards

-- 
Tomas Vondra