Обсуждение: minimum Meson version

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.

[0]: https://dl.rockylinux.org/pub/rocky/8/Devel/x86_64/os/Packages/m/

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
ifit 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
listif 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

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 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

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

Andres Freund <andres@anarazel.de> writes:
> 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

This seems like a reasonable policy skeleton.  As for $age_criteria,
I'd personally be satisfied with your option (e), which I'd rephrase
slightly as

  If the expected PG major version release date is after the end of
  maintenance support for an LTS distribution, that OS version does
  not need to be supported.

Given your rule (2), we'd still be on the hook to maintain back-branch
support for an EOL'd OS for five years, so I don't think that we need
to make the master-branch $age_criteria account for "extended
lifecycle".

In the context of RHEL, it says here [1] that RHEL8 maintenance
support runs through May 2029 while extended support runs through
May 2031.  That would still mean we're supporting RHEL8 for another
four years.  I'm not sure what the corresponding dates are for
other LTS vendors.

            regards, tom lane

[1] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle

I wrote:
> In the context of RHEL, it says here [1] that RHEL8 maintenance
> support runs through May 2029 while extended support runs through
> May 2031.  That would still mean we're supporting RHEL8 for another
> four years.  I'm not sure what the corresponding dates are for
> other LTS vendors.

I checked Debian and SUSE and noted that their "extended support"
windows are a lot shorter than RHEL's, just two or three years.
So maybe we shouldn't buy into RHEL's five-year window.  I do take
Jelte's point that it's unlikely somebody wants to run a bleeding-edge
PG release on a platform that's many years out from end of full
support; if they are using such a platform they probably prize
stability above all else.

Maybe we could compromise on

  If the expected PG major version release date is more than N years
  after the end of full support for an LTS distribution, that OS
  version does not need to be supported.

Defining it relative to "full support" also reduces questions about
whether extended support means the same thing to every LTS vendor.

If we set N=2 then we could drop RHEL8 support in PG 19; if we
set N=3 then it'd be PG 20 (measuring from end of full support
in May 2024).  I'd be okay with either outcome.

            regards, tom lane

On 18.06.25 19:53, Andres Freund wrote:
> 1) We don't remove support for OS versions unless they block something

Maybe it's worth clarifying the interpretation of this.

For example, for the purpose of this thread, I wouldn't consider RHEL8 
to be blocking anything at the moment.  It's technically blocking moving 
the meson requirement past some version, but that in turn isn't really 
blocking anything.  You can always find a new feature in any build 
dependency that you might want to use but don't really have to.

(Also, they sometimes ship updated python or openssl versions, for 
example, so there is also a possible difference between support in its 
original version, support with updates, and no support at all.)

But as another example, if by some miraculous development we decided to 
drop autoconf for PG19, then RHEL8 would block that, but then (by some 
of the policies a-e) we could drop RHEL8 support.

But my intuition is that if we did that right now, many vendors would 
just have to patch the support back in, which could be great consulting 
money, but wasteful overall.  So if the age cutoff landed on today, it 
might be too early.  (Or I suppose by your rule #4 they could just keep 
supplying upstream patches to keep the support alive.)

(I initially thought that RHEL8 was a typo for RHEL7, because we still 
support RHEL7!!  We should drop that first!)

Peter Eisentraut <peter@eisentraut.org> writes:
> On 18.06.25 19:53, Andres Freund wrote:
>> 1) We don't remove support for OS versions unless they block something

> Maybe it's worth clarifying the interpretation of this.

> For example, for the purpose of this thread, I wouldn't consider RHEL8 
> to be blocking anything at the moment.  It's technically blocking moving 
> the meson requirement past some version, but that in turn isn't really 
> blocking anything.

It's not the meson version that's the problem with RHEL8, it's the
ninja version, which is blocking our *use* of meson (and therefore
blocking removal of autoconf).

> (Also, they sometimes ship updated python or openssl versions, for 
> example, so there is also a possible difference between support in its 
> original version, support with updates, and no support at all.)

Right.  I think it's fair to say that we'll support only fully-updated
installations.

> (I initially thought that RHEL8 was a typo for RHEL7, because we still 
> support RHEL7!!  We should drop that first!)

As per Andres' proposed rule 1, we won't drop support for an old
version until it's blocking some change we want to make.  In this
context it wouldn't surprise me a bit if we end up dropping RHEL7
and RHEL8 at the same time and for the same reason (ie, lack of
new-enough meson/ninja packages).

            regards, tom lane

Hi,

On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> 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.

Thanks for the patches! I didn't check them yet but I encountered some
errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
0.58.0 worked successfully. These errors seem to be related to these
specific minor versions, but I just wanted to mention them:

- meson install command fails on 0.57.0:

FAILED: src/interfaces/ecpg/preproc/preproc.y
/usr/bin/perl ../../postgres/src/interfaces/ecpg/preproc/parse.pl
--srcdir @CURRENT_SOURCE_DIR@ --parser
../../postgres/src/interfaces/ecpg/preproc/../../../backend/parser/gram.y
--output src/interfaces/ecpg/preproc/preproc.y
Died at ../../postgres/src/interfaces/ecpg/preproc/parse.pl line 698.

- meson test command fails on 0.57.1:

Exception in callback TestHarness._run_tests.<locals>.test_done() at
/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py:1807
handle: <Handle TestHarness._run_tests.<locals>.test_done() at
/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py:1807>
Traceback (most recent call last):
  File "/usr/lib/python3.13/asyncio/events.py", line 89, in _run
    self._context.run(self._callback, *self._args)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1809, in test_done
    f.result()
    ~~~~~~~~^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1804, in run_test
    res = await test.run(self)
          ^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1350, in run
    await self._run_cmd(harness, cmd)
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1416, in _run_cmd
    returncode, result, additional_error = await p.wait(self.runobj.timeout)
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1242, in wait
    await try_wait_one(p.wait(), timeout=timeout)
  File "/home/nbyavuz/Desktop/projects/meson/meson/mesonbuild/mtest.py",
line 1133, in try_wait_one
    await asyncio.wait(awaitables,
                       timeout=timeout, return_when=asyncio.FIRST_COMPLETED)
  File "/usr/lib/python3.13/asyncio/tasks.py", line 448, in wait
    raise TypeError("Passing coroutines is forbidden, use tasks explicitly.")
TypeError: Passing coroutines is forbidden, use tasks explicitly.
/usr/lib/python3.13/asyncio/events.py:89: RuntimeWarning: coroutine
'Process.wait' was never awaited
  self._context.run(self._callback, *self._args)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
> Thanks for the patches! I didn't check them yet but I encountered some
> errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
> 0.58.0 worked successfully. These errors seem to be related to these
> specific minor versions,

I think it's okay to expect that users use the latest patch version of a 
particular version.  So we don't need to concern ourselves with this 
particular problem.

Hi,

Hi,

On 2025-06-18 10:58:22 +0200, Peter Eisentraut wrote:
> 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.

If you use declare_dependency(), older versions can't use compiler tests like
check_header() that reference that dependency.  I.e. if the tests pass with
0.57 after simplifying this, it's fine.



> 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.)

Agreed. Looks like that came in with bc46104fc9aa


> 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.

IDK about fatal meson warnings, at least on windows and macos, where we will
quickly upgrade the meson version to something new. That likely would lead to
a bunch of noisy build failures. It'd probably be fine if we enabled it on
linux.



> @@ -3898,106 +3887,102 @@ endif
>  # The End, The End, My Friend
>  ###############################################################
>  
> -if meson.version().version_compare('>=0.57')
> +summary(
> +  {
> +    'data block size': '@0@ kB'.format(cdata.get('BLCKSZ') / 1024),
> +    'WAL block size': '@0@ kB'.format(cdata.get('XLOG_BLCKSZ') / 1024),
> +    'segment size': get_option('segsize_blocks') != 0 ?
> +      '@0@ blocks'.format(cdata.get('RELSEG_SIZE')) :
> +      '@0@ GB'.format(get_option('segsize')),
> +  },
> +  section: 'Data layout',
> +)

I didn't look through this part of the diff, I assume it's just reindenting.

The rest looks good to me.

Greetings,

Andres Freund

Peter Eisentraut <peter@eisentraut.org> writes:
> On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
>> Thanks for the patches! I didn't check them yet but I encountered some
>> errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
>> 0.58.0 worked successfully. These errors seem to be related to these
>> specific minor versions,

> I think it's okay to expect that users use the latest patch version of a 
> particular version.  So we don't need to concern ourselves with this 
> particular problem.

That conclusion might be hard to sustain if there's some LTS distro
using not-the-latest patch version.  However, I don't believe that's
an issue for these particular meson versions.

We should, however, document that the minimum meson version is 0.57.2
not just 0.57, if we're aware of issues like this.

            regards, tom lane

Hi,

On Thu, 19 Jun 2025 at 09:40, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> Hi,
>
> On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut <peter@eisentraut.org> wrote:
> >
> > 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.
>
> Thanks for the patches! I didn't check them yet

All patches LGTM. I spent some time on using debug python interpreter
on Windows CI images to fix this warning:

    WARNING: Using a debug build type with MSVC or an MSVC-compatible compiler
    when the Python interpreter is not also a debug build will almost
    certainly result in a failed build. Prefer using a release build
    type or a debug Python interpreter.

I used the 'Include_debug' option [1] while installing python and
python_d.exe was created but a warning is still produced by meson.
Meson produces that warning if the 'Py_DEBUG' flag is not set in the
python build [2]. It seems that although it is a debug python build,
'Py_DEBUG' is not set.

I confirm it is a debug build because when I run python_d.exe with -d
flag, I can see the parser debugging output [3].

[1] https://docs.python.org/3/using/windows.html#installing-without-ui
[2]
https://github.com/mesonbuild/meson/blob/852a580ee6ed32bd21303e977556008de7918651/mesonbuild/dependencies/python.py#L257C1-L262C64
[3] https://docs.python.org/3/using/configure.html#python-debug-build
[3]
$ python3 -h
$ -d     : turn on parser debugging output (for experts only, only works on
           debug builds); also PYTHONDEBUG=x

--
Regards,
Nazir Bilal Yavuz
Microsoft

On 19.06.25 14:24, Andres Freund wrote:
>> 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.)
> Agreed. Looks like that came in with bc46104fc9aa

I have committed and backpatched this.

I'll park the rest of the patch set until PG19 opens.

Re: Tom Lane
> I checked Debian and SUSE and noted that their "extended support"
> windows are a lot shorter than RHEL's, just two or three years.
> So maybe we shouldn't buy into RHEL's five-year window.

Fwiw, what we are doing for apt.postgresql.org and Debian is to
support LTS which extends Debian (old)stable to 5 years:

https://wiki.debian.org/LTS/

That loosely matches the 5 year support window for Ubuntu's LTS
releases, so the oldest Debian and Ubuntu releases often get removed
from apt.pg.o around the same time. (It also matches PG's own 5 years
of support, so there's rarely any extra backpatching to do.)

We are not supporting ELTS for either distro. After around 5 years,
supporting all the various extensions starts getting painful because
compatibility issues with new upstream versions accumulate. Current
top issues are "cmake too old" and "pybuild-plugin-pyproject missing",
but it has been worse in the past. There are people keeping the server
packages patched for Debian ((old)old)oldoldstable, though:

https://wiki.debian.org/LTS/Extended

Christoph

On 22.06.25 15:12, Peter Eisentraut wrote:
> On 19.06.25 14:24, Andres Freund wrote:
>>> 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.)
>> Agreed. Looks like that came in with bc46104fc9aa
> 
> I have committed and backpatched this.
> 
> I'll park the rest of the patch set until PG19 opens.

I have committed this.

(without meson setup --fatal-meson-warnings)

On Wed, Jun 18, 2025 at 11:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maybe we could compromise on
>
>   If the expected PG major version release date is more than N years
>   after the end of full support for an LTS distribution, that OS
>   version does not need to be supported.
>
> Defining it relative to "full support" also reduces questions about
> whether extended support means the same thing to every LTS vendor.
>
> If we set N=2 then we could drop RHEL8 support in PG 19; if we
> set N=3 then it'd be PG 20 (measuring from end of full support
> in May 2024).  I'd be okay with either outcome.

I see that RHEL8 support is ending [1], hooray! Are we comfortable
applying the "N=2" rule to all of our LTS targets? And is this thread
the de facto policy going forward?

--Jacob

[1] https://yum.postgresql.org/news/news-rhel8-end-of-life/