Re: Meson far from ready on Windows - Mailing list pgsql-hackers

From Dave Page
Subject Re: Meson far from ready on Windows
Date
Msg-id CA+OCxowhJWujaPXZ5HuDiPkOoCBz5vQALorCapDnDyKnBuk86A@mail.gmail.com
Whole thread Raw
In response to Re: Meson far from ready on Windows  (Andres Freund <andres@anarazel.de>)
Responses Re: Meson far from ready on Windows
List pgsql-hackers
Hi

On Sat, 22 Jun 2024 at 17:32, Andres Freund <andres@anarazel.de> wrote:
> I don't think it's unreasonable to not support static linking, but I take
> your point.

Separately from this thread: ISTM that on windows it'd be quite beneficial to
link a few things statically, given how annoying dealing with dlls can be?
There's also the perf issue addressed further down.

Dealing with DLLs largely just boils down to copying them into the right place when packaging. The perf issue is a much more compelling reason to look at static linking imho.
 


> My assumption all along was that Meson would replace autoconf etc. before
> anything happened with MSVC, precisely because that's the type of
> environment all the Postgres devs work in primarily. Instead we seem to
> have taken what I think is a flawed approach of entirely replacing the
> build system on the platform none of the devs use, whilst leaving the new
> system as an experimental option on the platforms it will have had orders
> of magnitude more testing.

The old system was a major bottleneck. For one, there was no way to run all
tests. And even the tests that one could run, would run serially, leading to
exceedingly long tests times. While that could partially be addressed by
having both buildsystems in parallel, the old one would frequently break in a
way that one couldn't reproduce on other systems. And resource wise it wasn't
feasible to test both old and new system for cfbot/CI.

Hmm, I've found that running the tests under Meson takes notably longer than the old system - maybe 5 - 10x longer ("meson test" vs. "vcregress check"). I haven't yet put any effort into figuring out a cause for that yet.
 
FWIW, dynamic linking has a noticeable overhead on other platforms too. A
non-dependencies-enabled postgres can do about 2x the connections-per-second
than a fully kitted out postgres can (basically due to more memory mapping
metadata being copied).  But on windows the overhead is larger because so much
more happens for every new connections, including loading all dlls from
scratch.

I suspect linking a few libraries statically would be quite worth it on
windows. On other platforms it'd be quite inadvisable to statically link
libraries, due to security updates, but for stuff like the EDB windows
installer dynamic linking doesn't really help with that afaict?

Correct - we're shipping the dependencies ourselves, so we have to rewrap/retest anyway.
 
--

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Proposal: Division operator for (interval / interval => double precision)
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Partial aggregates pushdown