Client-only Meson Build From Sources

On 20.10.25 22:43, Benjamin Leff wrote:

Are there any plans to support a client-only (no server) build in meson?

I'm not aware of such plans. But that doesn't mean somebody couldn't
propose one.

Peter Eisentraut <peter@eisentraut.org> writes:

On 20.10.25 22:43, Benjamin Leff wrote:

Are there any plans to support a client-only (no server) build in meson?

I'm not aware of such plans. But that doesn't mean somebody couldn't
propose one.

Years ago we had support for client-only builds on at least some
toolchains (MSVC at least, not sure about elsewhere). That got
dropped though. 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. I think that
that argument hasn't lost its force, so we'd be likely to reject any
such proposal.

regards, tom lane

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.

--
Benjamin W. Leff
(516) 754-3453

On Tue, Oct 21, 2025 at 9:57 AM Tom Lane <tgl@sss.pgh.pa.us> 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.

regards, tom lane

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

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

[image: ltp|17647911066367886]

Hey All

Wanted to follow up going into the new year.

For our use case installing a subset of the tree is sufficient.

In order of preference / difficulty:
1) Subset of tree
2) Subset of libs / binaries
3) Configure-time switch to only build client binaries

Is there enough interest to do #1? How can I help?

Happy New Year,
Benjamin

--
Benjamin W. Leff

On Wed, Dec 3, 2025 at 2:16 PM Benjamin Leff <benjamin.w.leff@gmail.com>
wrote:

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

[image: ltp|17647911066367886]

[image: ltp|17673783065384987]

Hi,

On 2026-01-02 12:43:34 -0600, Benjamin Leff wrote:

For our use case installing a subset of the tree is sufficient.

In order of preference / difficulty:
1) Subset of tree

What precisely do you mean by this?

2) Subset of libs / binaries

Why is 1) peferrable over 2)?

3) Configure-time switch to only build client binaries

I really doubt there's interest in going there.

FYI, on the postgres list we try to quote properly, quoting the old message at
the bottom of your email, without any trimming, is likely to lead to fewer
responses.

Greetings,

Andres Freund

Hi Andres,

Apologies for the poor communication.

On 2026-01-02 12:48:34, Andres Freund wrote:

On 2026-01-02 12:43:34 -0600, Benjamin Leff wrote:

For our use case installing a subset of the tree is sufficient.

In order of preference / difficulty:
1) Subset of tree

What precisely do you mean by this?

Poor communication on my part. When I said "in order of preference /
difficulty" I meant in order of difficulty/ease of implementation for
maintainers (that also satisfies our needs), not our actual preference.

Said differently, let's start with the easiest / lowest hanging fruit first
to minimize maintenance burden. A meta target that builds only client
portions of the tree seems like the lightest-weight approach.

2) Subset of libs / binaries

Why is 1) peferrable over 2)?

It's not (again I communicated poorly). #2 (install target filtering
specific libs/binaries) would actually be better for our use case since it
saves both build time and disk space. But since you mentioned #2 would be
"slightly harder" in your earlier email, I was trying to suggest we tackle
#1 first if that's easier to implement and maintain.

3) Configure-time switch to only build client binaries

I really doubt there's interest in going there.

Understood.

I'm happy to help however I can and support the approach that makes the
most sense from a maintenance perspective.

Let me know if that helps clarify!

Thanks,
Benjamin

--
Benjamin W. Leff

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<https://aka.ms/LearnAboutSenderIdentification&gt;
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<mailto:andres@anarazel.de>> wrote:
Hi,

On 2025-10-21 12:02:27 -0400, Tom Lane wrote:

Benjamin Leff <benjamin.w.leff@gmail.com<mailto: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]

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!

If this feature doesn't move forward in postgres, if you're interested,
would love the help syncing our stripped down fork with upstream.

I'm also not particularly keen on adding a dependency on autoconf/make

This is true for us too. We're trying to reduce all reliance on autoconf.

--
Benjamin W. Leff

On Thu, Jan 15, 2026 at 12:29 PM Jaroslaw Ciba <jaroslaw.ciba@carallon.com>
wrote:

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

[image: ltp|17685019294754567]

Hi,

On 2026-01-15 18:29:43 +0000, Jaroslaw Ciba wrote:

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!

What specifically do you mean with a stripped down libpq? Just without
optional dependencies, which certainly do increase the installed size, or
something more?

With autoconf it is trivial to get a client-side version only - just 4 make
commands do the trick.

It'd be a few lines to add a 'libpq' and 'install-libpq' targets, I assume
that'd do the trick for you? I assume you also need the headers being
installed?

Greetings,

Andres Freund