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