Re: MPTCP - multiplexing many TCP connections through one socket to get better bandwidth

On Tue, Aug 18, 2026 at 5:19 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
>
> Thanks for v4! Took a heavier look. Code applies cleanly to 033f39e694872d8d74e670a20093db781eb0bf61, is indented properly, and passes make check.

Hi Greg, cool, thanks for reviewing!

> > <term><literal>MPTCP</literal><indexterm><primary>MultiPath TCP</primary></indexterm></term>
>
> s/MultiPath/Multipath/ (other places like the commit message too)

Fixed

> > (multiplexing) over mulitple network paths, provided that remote also
>
> s/mulitple/multiple/

Fixed

> src/backend/libpq/pqcomm.c
[..]
> It's already 0 from the top of the loop, so it should be enough to do:
>
> #ifdef IPPROTO_MPTCP
> if (ListenMPTCP && addr->ai_family != AF_UNIX)
> socket_protocol = IPPROTO_MPTCP;
> #endif

Absolutely yes, fixed.

> src/backend/utils/misc/postgresql.conf.sample
> > #listen_mptcp = off # whether to enable Multipathing TCP or not
>
> s/Multipathing/Multipath/
>
> Or just: # enable Multipath TCP
>
> Can we move to a less prominent place - perhaps under TCP, after client_connection_check_interval?

Sure thing, both things fixed

> src/interfaces/libpq/fe-connect.c
> > {"mptcp", "PGMPTCP", "0", NULL,
>
> Does this need freeing in freePGconn()?

Good catch, added it there.

> src/interfaces/libpq/fe-connect.c
> > if (addr_cur->family != AF_UNIX && conn->mptcp && conn->mptcp[0] == '1')
> > {
> > #ifdef IPPROTO_MPTCP
> > fprintf(stderr, "enabling MPTCP client\n");
> > ip_protocol = IPPROTO_MPTCP;
> > #else
> > fprintf(stderr, "MPTCP client is not supported on this platform\n");
> > #endif
>
> We should throw a proper message to the user if they attempt mptcp via tcp, but don't have it enabled by using the libpq_append_conn_error function.

Thanks for the hint, improved

> Don't know if a warning for attempting mptcp on via unix socket is worth it.

I don't think so, we should just ignore it I think.

> I'm not clear on the mptcp[0] == '1' bit - does that mean the only way to invoke it is exactly this?:
>
> PGMPTCP=1
>
> (or I suppose, any other string starting with "1")

Exactly, I'm not sure if there's better way, should we parse "on" / "true"
maybe?

> Big picture: is it worth making this more generic, in case other protocols appear some time in the future?
>
> listen_mptcp = on -> listen_protocol = mptcp
> PGMPTCP=1 -> PGSOCKETPROTOCOL=mptcp
>

Awesome question. I've started thinking and the hypothethical list could
include:
* SCTP (got no adoption, it's long time dead because it used different
layer3 protocol than just TCP/UDP and corporate firewallls kiled it, sic!)
* QUIC (the thing for HTTP/3 which apparently has similiar MP-QUIC too;
works over UDP but that would be different userspace beast and even if
listen_quic=on/quic=on also looks good to me)
* and there's potentially kind of extreme/hard-core/sci-fi case of RDMA
world (RoCEv2/Infiniband) which could be used for libpq, but that would
seem like great fit for low latency stuff, but probably would be very
hard to integrate into libpq (it has no apparently no classic BSD sockets
/fds API). Dunno what would be real usecase for that though (very-close-
proximity backups/replicas/caches only? that thing requires lossless
>=100GbE ethernet), but we could see it one day

You ask how we could extend PostgreSQL in future with this and I'm both
fine with listen_<X> and listen_protocols=tcp,[mptcp,quic,etc] which
would be more future proof for sure, just also I don't know which
path to take.

Anyway, client-side "PGSOCKETPROTOCOL" also sounds as cool name/way to
enable it.

> On re-reading this email, that doesn't allow us to handle different protocols for different families, so listen_mptcp is fine.

I'm fine with both ways to be honest. Let's leave it like this and if
there are voices strictly in favor of PGSOCKETPROTOCOL/listen_protocols
we can adapt to that, ok?

> This new ENV should be added to the lists at src/test/perl/PostgreSQL/Test/Utils.pm and src/test/regress/pg_regress.c

Done, thanks

> Ideally also some tests.

I've added some easy minimal testing to the postmaster's suite, where I think
this had best fit.

-J.