Re: contrib/pg_stat_tcpinfo

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: contrib/pg_stat_tcpinfo
Date: 2025-11-08 00:18:20
Message-ID: bbsehqdl667gadx4rpkntgufunu2vpb4rrkqzroxhyfzuxupjc@dyujozzksnz4
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-11-08 00:17:30 +0100, Tomas Vondra wrote:
> On 11/7/25 11:36, Jakub Wartak wrote:
> > On Mon, Nov 3, 2025 at 3:09 PM Jakub Wartak
> > <jakub(dot)wartak(at)enterprisedb(dot)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.

FWIW, I've needed this many times. Without the TCP information it's very hard
to figure out why higher latency connections aren't keeping up - is it packet
loss, it it too small network buffers on the sending/receiving side, is it the
remote side not keeping up on the CPU level...

> >> 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?

I'd expect it to be mainly in prod, although not exclusively.

> >> 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?

Yea, I don't get that either - IMO ss's format is just about the worst
possible format. It's very hard to parse and doesn't seem to have advantages
making up for that.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-11-08 00:24:24 Re: IO in wrong state on riscv64
Previous Message Jacob Champion 2025-11-08 00:14:58 Re: Thoughts on a "global" client configuration?