minimum Meson version

Peter Eisentraut <peter@eisentraut.org> writes:

I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
good target to aim for. (I don't know if that carried over from RHEL 8
or is their own doing.) But there aren't any compelling features new in
0.58 (format strings seem nice but are pretty much cosmetic), so maybe
setting the minimum to 0.57 is enough.

RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
which is too old:

$ meson setup build
...
Found ninja-1.8.2 at /usr/bin/ninja
ninja: error: build.ninja:7378: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

WARNING: Could not create compilation database.

So in the Red Hat universe, the first release that has usable meson
infrastructure for our purposes is RHEL 9, which has meson 0.63.3
and ninja 1.10.2. Not sure how that factors into this calculation.
But unless we can back off our minimum ninja version, it's going
to be a long time before we can abandon the makefiles.

regards, tom lane

Hi,

On 2025-06-17 13:48:33 -0400, Tom Lane wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
good target to aim for. (I don't know if that carried over from RHEL 8
or is their own doing.) But there aren't any compelling features new in
0.58 (format strings seem nice but are pretty much cosmetic), so maybe
setting the minimum to 0.57 is enough.

RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
which is too old:

$ meson setup build
...
Found ninja-1.8.2 at /usr/bin/ninja
ninja: error: build.ninja:7378: multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you

WARNING: Could not create compilation database.

IIRC we discussed this before, in some other thread. We could make that work,
but at the time we didn't consider it worth working on.

So in the Red Hat universe, the first release that has usable meson
infrastructure for our purposes is RHEL 9, which has meson 0.63.3
and ninja 1.10.2. Not sure how that factors into this calculation.
But unless we can back off our minimum ninja version, it's going
to be a long time before we can abandon the makefiles.

From my POV, which I am sure is not uniformly shared, we don't need to support
new major PG versions on things like RHEL 8. After all full support for RHEL 8
has ended a year ago.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

On 2025-06-17 13:48:33 -0400, Tom Lane wrote:

RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
which is too old:

IIRC we discussed this before, in some other thread. We could make that work,
but at the time we didn't consider it worth working on.

Yeah, we've definitely been over that before. I think at the time
we were still in the mode of "get meson to work at all", and so it
didn't seem high priority. But it's the sort of cleanup we need
to start thinking about if we want meson to be our only build system.

From my POV, which I am sure is not uniformly shared, we don't need to support
new major PG versions on things like RHEL 8. After all full support for RHEL 8
has ended a year ago.

Nope, I don't share that opinion. RHEL 8 will be a perfectly usable
platform at least through 2029 (when maintenance support will stop,
according to wikipedia). And LTS platforms like that are our bread
and butter for real-world use.

regards, tom lane

Hi,

On 6/17/25 2:23 PM, Andres Freund wrote:

After all full support for RHEL 8 has ended a year ago.

Yes, full support ended May 31, 2024 - but extended support ends May 31,
2029.

Devrim, feedback ?

Best regards,
Jesper

Hi,

On 2025-06-17 14:33:39 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2025-06-17 13:48:33 -0400, Tom Lane wrote:

RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
which is too old:

IIRC we discussed this before, in some other thread. We could make that work,
but at the time we didn't consider it worth working on.

Yeah, we've definitely been over that before. I think at the time
we were still in the mode of "get meson to work at all", and so it
didn't seem high priority. But it's the sort of cleanup we need
to start thinking about if we want meson to be our only build system.

I just went over the relevant cases:

1) older ninja complains about doc/src/sgml target having multiple outputs
(man1, man3, man7)

I wonder if we could just make that easier by changing our scripts to
create those directories within one man/ directory?

Alternatively we could just use less accurate dependencies for older
versions.

2) older ninja complains about dependency loop for snowball_create.sql

That's easily addressed by combining the dependency output lines

3) older ninja complains about sql_help.h/.c

Not sure what the best way is here, one way would be to create the two
files in separate invocations.

After hacking up those three cases it seems to work here.

Greetings,

Andres Freund

On Tue, Jun 17, 2025 at 2:23 PM Andres Freund <andres@anarazel.de> wrote:

From my POV, which I am sure is not uniformly shared, we don't need to
support
new major PG versions on things like RHEL 8.

Ha ha ha ha! (wipes tears from eyes). RHEL 8 is still cutting edge / very
active for many companies out there. And it's officially supported for many
years to come.

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Hi,

On 2025-06-17 16:09:19 -0400, Greg Sabino Mullane wrote:

On Tue, Jun 17, 2025 at 2:23 PM Andres Freund <andres@anarazel.de> wrote:

From my POV, which I am sure is not uniformly shared, we don't need to
support
new major PG versions on things like RHEL 8.

Ha ha ha ha! (wipes tears from eyes).

Thanks for that, ... uh ... , thoughful response.

RHEL 8 is still cutting edge / very active for many companies out there. And
it's officially supported for many years to come.

Please do note that I was not suggesting removing support for it from minor
versions and that the earliest we, IMO, would conceivably remove autoconf
support would be PG 20.

I'm sure there will be some folks desperate to run PG 20 on RHEL 8, ~3 years
after main support ended, 2 years before end of maintenance support, but it
won't be that many. And for those it still wouldn't be hard, they'd need to
install some up2date dependencies, but that's the price for doing something
that's a really really bad practice.

Andres Freund

On Tue, 17 Jun 2025 at 22:19, Andres Freund <andres@anarazel.de> wrote:

Please do note that I was not suggesting removing support for it from minor
versions and that the earliest we, IMO, would conceivably remove autoconf
support would be PG 20.

I'm sure there will be some folks desperate to run PG 20 on RHEL 8, ~3 years
after main support ended, 2 years before end of maintenance support, but it
won't be that many. And for those it still wouldn't be hard, they'd need to
install some up2date dependencies, but that's the price for doing something
that's a really really bad practice.

+many. I really don't understand why we go so far out of our way to
support compiling and running tests with a completely unmodified
ancient RHEL system.

I'm not saying we shouldn't support compiling Postgres on these
systems. But having Postgres compile with just the default system
packages seems an unreasonably high bar. People running ancient
systems like this should be comfortable enough with getting some more
recent build dependencies. Recent meson and ninja executables are just
a "pip install" away, even on RHEL8.

On 17.06.25 23:10, Jelte Fennema-Nio wrote:

I'm not saying we shouldn't support compiling Postgres on these
systems. But having Postgres compile with just the default system
packages seems an unreasonably high bar. People running ancient
systems like this should be comfortable enough with getting some more
recent build dependencies. Recent meson and ninja executables are just
a "pip install" away, even on RHEL8.

That's probably ok for developers, but then again, probably no one
develops PostgreSQL master on RHEL 8. But production RPM builds need to
be done "in system", with the build tools being provided by
vendor-supplied RPMs themselves, with all the signatures, attestations,
and all that stuff that comes with it nowadays.

On Wed, 18 Jun 2025 at 07:38, Peter Eisentraut <peter@eisentraut.org> wrote:

That's probably ok for developers, but then again, probably no one
develops PostgreSQL master on RHEL 8. But production RPM builds need to
be done "in system", with the build tools being provided by
vendor-supplied RPMs themselves, with all the signatures, attestations,
and all that stuff that comes with it nowadays.

Okay, so maybe pip install is not what they want. But they could still
create a recent ninja & meson RPM themselves right. I assume they know
how to do that, because they'd need to do the same for PostgreSQL too
if they care about all the things you mentioned.

And what I just don't understand about this whole discussion: We're
talking about people who want to be frozen in time for 5 years
straight during this "maintenance support" window by the vendor (whom
they are paying), with only access to security fixes. But somehow they
do want to run the latest Postgres Major release, even though the one
that they had running still receives bug fixes and security fixes. I
just don't understand who these people are. Why do they care about
having no changes to their system to avoid breakage as much as
possible, except for their piece of primary database software, of
which they're happily running the bleeding edge.

On 17.06.25 19:36, Peter Eisentraut wrote:

meson.build currently says

# We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
# RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
# module, < 0.53 all uses of fs. So far there's no need to go to >=0.56.
meson_version: '>=0.54',

Since the current minimum supported Python version is now actually 3.6,
we could update this a bit.

The first Meson version to require Python 3.7 is 0.62, so we should stay
below that.

Moving to 0.55 and 0.56 would get rid of some future-deprecated warnings.

There is some conditional code for 0.57 and 0.59, so landing on either
of these would allow getting rid of some of that.

I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
good target to aim for.  (I don't know if that carried over from RHEL 8
or is their own doing.)  But there aren't any compelling features new in
0.58 (format strings seem nice but are pretty much cosmetic), so maybe
setting the minimum to 0.57 is enough.

Ok, let's make a small start. Here is a patch set that moves the
requirement to >=0.57. As explained above, this allows getting rid of a
bunch of conditional code and the future-deprecated warnings.

There is one mention that I didn't dare touch:

if have_gssapi
# Meson before 0.57.0 did not support using check_header() etc with
# declare_dependency(). Thus the tests below use the library looked up
# above. Once we require a newer meson version, we can simplify.
gssapi = declare_dependency(dependencies: gssapi_deps)
endif

I didn't quite understand what was meant by this. This code is
relatively new, so maybe someone who worked on it still remembers and
can offer a suggestion.

Along the way, I also found that our meson.build always issues a warning
when run on Windows/msvc, which I fixed. (Should probably be backpatched.)

To help find all the places to update for deprecations etc., I used the
option meson setup --fatal-meson-warnings. This seems quite useful, so
I'm also suggesting adding it to the CI tasks. I think this could be
useful in general, as I've seen more than zero times someone submitting
a patch that accidentally violates the meson version requirement in some
way, and we might as well catch those early.

On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

And what I just don't understand about this whole discussion:

What I just don't understand about this discussion is a bunch of smart
people thinking that a bunch of other smart people have completely
lost their minds, while the second group thinks exactly the same about
the first group. There's hardly a topic to be found that produces more
apparent acrimony around here than what releases of things we ought to
still be supporting.

--
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

And what I just don't understand about this whole discussion:

What I just don't understand about this discussion is a bunch of smart
people thinking that a bunch of other smart people have completely
lost their minds, while the second group thinks exactly the same about
the first group. There's hardly a topic to be found that produces more
apparent acrimony around here than what releases of things we ought to
still be supporting.

Indeed. I think the compromise we've usually settled on is "we'll
support release X as long as there's somebody willing to do the work".
If it's not costing you personally any effort, why object to someone
else wanting to spend effort on such things?

regards, tom lane

Hi,

On 2025-06-18 12:27:44 -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

And what I just don't understand about this whole discussion:

What I just don't understand about this discussion is a bunch of smart
people thinking that a bunch of other smart people have completely
lost their minds, while the second group thinks exactly the same about
the first group. There's hardly a topic to be found that produces more
apparent acrimony around here than what releases of things we ought to
still be supporting.

Indeed. I think the compromise we've usually settled on is "we'll
support release X as long as there's somebody willing to do the work".
If it's not costing you personally any effort, why object to someone
else wanting to spend effort on such things?

I don't think that's what we settled on *at all*, we rather settled on the
polar opposite.

Anyone that does work that is affected by support for old operating systems
has to either spend tremenduous energy arguing that we should remove support
for $old_os or spend tremenduous energy inventing workaround for $old_os.

I.e. folks demanding continued support for old operating systems do very
little work, whereas the folks that actually are affected a lot of time. It's
*tremendously* demotivating.

For some recent examples take this thread or the discussion about removing
support for old openssl versions. How can either of those be described as
folks wanting to support old operating systems doing work?

Greetings,

Andres Freund

On Wed, Jun 18, 2025 at 6:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Indeed. I think the compromise we've usually settled on is "we'll
support release X as long as there's somebody willing to do the work".
If it's not costing you personally any effort, why object to someone
else wanting to spend effort on such things?

I don't think this is really the issue. It's usually - as here - about
what we could clean up or simplify by removing support for old
versions, as against the inconvenience caused to people who still want
to use those old versions. So it's often the people who are
volunteering to do the work want to break things for the people who
aren't doing anything except objecting to the breakage.

But it seems impossible to have rational discussions about this,
because - if I may exaggerate slightly for effect - some of us think
everyone with half a brain should upgrade within a week or two when a
new version comes out, while others of us think that there might be
someone out there who still has a working PDP-11. Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.

--
Robert Haas
EDB: http://www.enterprisedb.com

Hi

On 6/18/25 1:07 PM, Robert Haas wrote:

Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.

Which is why I tried to add Devrim to the thread.

What builds on yum.postgresql.org are using meson ? If none of the RHEL
8 ones are then the minimum requirements for ninja and meson can be
bumped to the minimum versions to the ones that are.

Devrim, feedback ?

Best regards,
Jesper

On Wed, Jun 18, 2025 at 3:35 AM Jelte Fennema-Nio <postgres@jeltef.nl>
wrote:

And what I just don't understand about this whole discussion: We're
talking about people who want to be frozen in time for 5 years
straight during this "maintenance support" window by the vendor (whom they
are paying), with only access to security fixes. But somehow they do want
to run the latest Postgres Major release, even though the one that they had
running still receives bug fixes and security fixes. I just don't
understand who these people are.

These are companies in which upgrading the OS is a Very Big Involved
Process, but they would still like to run a recent version of Postgres.

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Hi,

On 2025-06-18 13:20:54 -0400, Jesper Pedersen wrote:

On 6/18/25 1:07 PM, Robert Haas wrote:

Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.

Which is why I tried to add Devrim to the thread.

What builds on yum.postgresql.org are using meson ? If none of the RHEL 8
ones are then the minimum requirements for ninja and meson can be bumped to
the minimum versions to the ones that are.

The context of the discussion is removing autoconf based builds eventually (in
some future major version). For that it doesn't really matter whether yum.pg.o
currently uses meson.

Greetings,

Andres Freund

Hi,

On 2025-06-18 19:07:32 +0200, Robert Haas wrote:

On Wed, Jun 18, 2025 at 6:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
But it seems impossible to have rational discussions about this,
because - if I may exaggerate slightly for effect - some of us think
everyone with half a brain should upgrade within a week or two when a
new version comes out, while others of us think that there might be
someone out there who still has a working PDP-11. Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.

Obviously that dynamic exists.

But I think the root cause here isn't that we fundamentally can't find any
compromise agreement, it's that we don't have a policy. Thus we get to have an
iteration of the same debate everytime somebody is blocked by $old_os. Leading
to everyone being incredibly frustrated and hardening their stances.

I think what we need to do is to finally formalize the policy around this that
we then can apply somewhat mechanical to most of the future cases.

I think we should have a policy roughly along these lines:

1) We don't remove support for OS versions unless they block something

2) We don't remove support for OS versions in minor releases

3) If support for an old OS version makes something harder, it can be removed,
if and only if the OS is older than $age_criteria.

4) As an alternative to removing OS support via 3), somebody desiring
continued support for an older OS version can instead do the work to
develop an alternative to removal of support within $reasonable_timeframe

Policy a)

Personally I would say that a reasonable $age_criteria would be:

If the expected PG major version release date is after the end of the "full
support" window of a LTS distribution, the OS does not need to be supported.

While I think that's rather reasonable, I *really* doubt that we could find
agreement on that.

Policy b)

An IMO completely unreasonable position would be:

If the expected PG major version release date is 5 years after the end of
the "extended lifecycle" window of a LTS distribution, the OS does not need
to be supported.

I doubt anyone would argue that we need to go that far.

Policy c)

I guess a more credible, but from my perspective still fairly extreme, "long
support window" position would be something like:

If the expected PG major version release date is after the end of the
"extended lifecycle" window of a LTS distribution, the OS does not need to
be supported.

To me that's too long support, because it means we'll support that major
version of PG for up to 5 years after the OS vendor stopped supporting that
version. BUT: I could live with that policy, even though I think it'd harm the
project.

Policy d)

An IMO more reasonable compromise position could be something like this:

If the expected PG major version release year + postgres support window (5
years) is after the year in which the "extended lifecycle" window of a LTS
distribution ends, the OS does not need to be supported.

That'd e.g. mean that PG 19 would need to support RHEL8, but PG 20 wouldn't,
since
$PG_20_release_year + $support_window > $RHEL_8_extended_lifecycle
2027 + 5 > 2031

That's personally still too aggressive for me, but I'd have an easier time
living with this than with c).

Policy e)

Just like d), except that we would use not the end of the "extended
lifecycle", but "end of maintenance support" as the cutoff.

Greetings,

Andres Freund