Re: Client-only Meson Build From Sources - Mailing list pgsql-hackers

From Jaroslaw Ciba
Subject Re: Client-only Meson Build From Sources
Date
Msg-id LOVP265MB8918D54D2147E85E384B896C9D8CA@LOVP265MB8918.GBRP265.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Client-only Meson Build From Sources  (Benjamin Leff <benjamin.w.leff@gmail.com>)
List pgsql-hackers
Hey all,

Just thought I would bump this thread given Benjamin has been the only one to request the feature thus far. It was nice to bump into this thread when I was evaluating client-side builds in December myself. 

We'd be interested in a stripped down libpq as well; a couple of our embedded Linux platforms built in Buildroot include PostgreSQL, and it accounts for roughly 15% and 20% of our firmware bundles respectively - one of the taller nails in the BSPs. Both of these platforms are only ever clients!

With autoconf it is trivial to get a client-side version only - just 4 make commands do the trick. As part of upgrading BSPs I considered adding an internal Buildroot package relying on this, given it's a good opportunity to go through smoke testing and see it not break anything, but I currently do not want to increase the maintenance burden in moving BSPs forward. I'm also not particularly keen on adding a dependency on autoconf/make given it's only been said it won't be dropped in the near future - I don't particularly want some developer here in 5 years' time to have to tear their hair out! Having this problem solved externally would be great, though I more than understand the need to balance resources.

Best,
Jaroslaw Ciba




From: Benjamin Leff <benjamin.w.leff@gmail.com>
Sent: 03 December 2025 20:16
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter@eisentraut.org>; pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: Client-only Meson Build From Sources
 
You don't often get email from benjamin.w.leff@gmail.com. Learn why this is important
Building only a subset of libraries / binaries would be sufficient for our use case (and even only building a subset of the tree would get us most of the way there). 

A configure-time switch to only build client binaries would be ideal but perhaps that could be a long term goal.

In our fork we tried to remove anything that wasn't relevant for having a functioning client. 

If this group is open to it, maybe we could figure out how to approach the low hanging fruit first.

Best,
Benjamin 



On Wed, Oct 22, 2025 at 4:02 AM Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2025-10-21 12:02:27 -0400, Tom Lane wrote:
> Benjamin Leff <benjamin.w.leff@gmail.com> writes:
> >> I believe the prevailing opinion was that the amount
> >> of time saved by not building all of PG didn't justify the maintenance
> >> effort to keep the build scripts working for that case
>
> > IMO, it’s not just about time. For bare bones package managers when there’s
> > no need to build the server, this saves a few GB.
>
> It's still fundamentally about trading off machine resources versus
> people time, though, and that tradeoff is not getting more attractive.

The impact really depends on what we define a client-only build as.

It'd not be hard at all to add a meta target that just builds a subset of the
tree. It'd be slightly harder, but still not that hard, to add a target to
install just a subset of libraries / binaries.

What would be a bit harder would be to add a configure-time switch to only
build client binaries. Mainly because, I think, it'd increase the test matrix
more than a dedicated build target would.

Benjamin, what precisely are you looking for with a client-only build?

Greetings,

Andres Freund
ltp|17647911066367886

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: remove the unneeded header file math.h in binaryheap.c
Next
From: Greg Burd
Date:
Subject: Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update)