Re: contrib/pg_stat_tcpinfo

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: contrib/pg_stat_tcpinfo
Date: 2026-10-16 09:25:18
Message-ID: CAKZiRmwgxy1-kNPEkBs2r1nBirVhtp1QQXK0EHwH6-63ZeAQuA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 23, 2026 at 7:27 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Mon, Nov 10, 2025 at 12:35 AM Jakub Wartak
> <jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
> >
> > On Sat, Nov 8, 2025 at 1:18 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > > 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...
> >
> > Pretty much the same!
>
> +1 (and I wish I had this today, in particular...)

I also remind myself about this only when it's needed, but then it's always
always already too late ;)

> > Still , it is still PoC, and I'm not sure if the community is open to
> > accept (or reject it).
>
> I think it's a useful concept.

OK, so to just get some more rapid movement, I've changed my mind a little
about this and I've marked in the commitfest as RwF, but I've fixed lots of
bugs since last reviews over period of couple months and turned this into
3rd party extension (it's available under
https://github.com/jakubwartakEDB/pg_stat_tcpinfo , supports BBR now and so on
). It seems that's a better vehicle for it. FWIW, we are already working as
making available through the standard repos.

-J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Álvaro Herrera 2026-10-16 08:45:33 Re: [PG19] pg_upgrade from <= 18 loses the newest multixid if its members end at offset wraparound