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

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MPTCP - multiplexing many TCP connections through one socket to get better bandwidth
Date: 2026-08-18 10:42:12
Message-ID: CAKZiRmxxL=fJEcqWrrU2-QDBeNu+9MTb-pxnaHmODxpQxXi07A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 17, 2026 at 10:19 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>
> On Thu, Aug 13, 2026 at 9:59 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
> >
> > I like the idea a lot. Have not tested yet, but the patch looks okay as a POC. I'm wondering if rather than a run-time check for IPPROTO_MCP in src/backend/libpq/pqcomm.c, we shouldn't check right away as soon as it is enabled via a guc check - see check_bonjour as a good example.
>
> Hi Greg, thanks for taking a look. I've attached v3 that added
> check_listen_mptcp() (GUC check) that enhanced the situation just as You
> have indicated.

Oops, I completely forgot about properly guarding this for non-Linux OS,
e.g. on FreeBSD complained that IPPROTO_MPTCP is unknown. Attached v4
fixes that.

-J.

Attachment Content-Type Size
v4-0001-Add-MPTCP-protocol-support-to-server-and-libpq-on.patch text/x-patch 9.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Keyerror Smart 2026-08-18 10:42:39 [PATCH] pgcrypto: Ensure debug handler is reset on error in PGP functions
Previous Message Ayush Tiwari 2026-08-18 10:37:05 Re: Error handling in after-startup shmem requests