Subject: AIX support

From: Sriram RK <[email-masked]>
Date: Thu, 21 Mar 2024 12:55:31 +0000

Hello Team,

We are working on AIX systems and noticed that the thread on removing AIX support in Postgres going forward.

https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b”

We would be glad to understand any outstanding issues hindering the support on AIX.
It is important for us to have Postgres to be supported on AIX. As we are using Postgres extensively on AIX.
Also we would like to provide any feasible support from our end for enabling the support on AIX.

We would request the community to extend the support on AIX ..

Thanks & regards,
Sriram.

---

From: Alvaro Herrera <[email-masked]>
Date: Thu, 21 Mar 2024 14:57:24 +0100

> We would be glad to understand any outstanding issues hindering the support on AIX.

There's a Discussion link at the bottom of that commit message.  I
suggest you read that discussion complete, and consider how much effort
you or your company are willing to spend on doing the maintenance of the
port yourselves for the community.  Maybe ponder this question: would it
be less onerous to migrate your Postgres servers to Linux, like Phil
Florent described on the currently-last message of that thread?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Para tener más hay que desear menos"

---

From: Tom Lane <[email-masked]>
Date: Thu, 21 Mar 2024 09:57:39 -0400

Sriram RK <[email-masked]> writes:
> https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b

Did you read the linked thread?  Starting say about here:

https://www.postgresql.org/message-id/flat/20240224172345.32%40rfd.leadboat.com#8b41e50c2190c82c861d91644eed9c30

> Also we would like to provide any feasible support from our end for enabling the support on AIX.

Who is "we", and how much resources are you prepared to put into this?

> We would request the community to extend the support on AIX ..

The community, in the sense of the existing people doing significant
work on Postgres, are absolutely not going to do that.  If you can
bring a bunch of work to fix all the problems noted in the discussion
thread, and commit to providing ongoing development manpower and
hardware to keep it working, maybe something could happen.  But I
suspect you will find it cheaper to start thinking about migrating
off AIX.

			regards, tom lane

---

From: Sriram RK <[email-masked]>
Date: Thu, 21 Mar 2024 16:35:26 +0000

Thanks, Tom and Alvaro, for the info.
We shall look into to details and get back.

From: Tom Lane <[email-masked]>
Date: Thursday, 21 March 2024 at 7:27 PM
To: Sriram RK <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: AIX support

                        regards, tom lane

---

From: Sriram RK <[email-masked]>
Date: Thu, 28 Mar 2024 11:09:43 +0000

Hi Team,

We are setting up the build environment and trying to build the source and also trying to analyze the assert from the Aix point of view.

Also, would like to know if we can access the buildfarm(power machines) to run any of the specific tests to hit this assert.

Thanks & regards,
Sriram.

  > From: Sriram RK <[email-masked]>
  > Date: Thursday, 21 March 2024 at 10:05 PM
  > To: Tom Lane [email-masked]<mailto:[email-masked]>, Alvaro Herrera <[email-masked]>
  > Cc: [email-masked]<mailto:[email-masked]> <[email-masked]>
  > Subject: Re: AIX support

---

From: Noah Misch <[email-masked]>
Date: Thu, 28 Mar 2024 19:48:32 -0700

> We are setting up the build environment and trying to build the source and also trying to analyze the assert from the Aix point of view.

The thread Alvaro and Tom cited contains an analysis.  It's a compiler bug.
You can get past the compiler bug by upgrading your compiler; both ibm-clang
17.1.1.2 and gcc 13.2.0 are free from the bug.

> Also, would like to know if we can access the buildfarm(power machines) to run any of the specific tests to hit this assert.

https://portal.cfarm.net/users/new/ is the form to request access.  It lists
the eligibility criteria.

---

From: Tom Lane <[email-masked]>
Date: Thu, 28 Mar 2024 23:07:42 -0400

> the eligibility criteria.

There might be some confusion here about what system we are talking
about.  The Postgres buildfarm is described at
https://buildfarm.postgresql.org/index.html
but it consists of a large number of individual machines run by
individual owners.  There would not be a lot of point in adding a
new AIX machine to the Postgres buildfarm right now, because it
would surely fail to build HEAD.  What Noah is referencing is
the GCC compile farm, which happens to include some AIX machines.
The existing AIX entries in the Postgres buildfarm are run (by Noah)
on those GCC compile farm machines, which really the GCC crowd have
been *very* forgiving about letting us abuse like that.  If you have
your own AIX hardware there's not a lot of reason that you should
need to access the GCC farm.

What you do need to do to reproduce the described problems is
check out the Postgres git tree and rewind to just before
commit 0b16bb877, where we deleted AIX support.  Any attempt
to restore AIX support would have to start with reverting that
commit (and perhaps the followup f0827b443).

			regards, tom lane

---

From: Srirama Kucherlapati <[email-masked]>
Date: Wed, 15 Oct 2025 15:58:58 +0000

Hi Andres and team,

Please find attached the patch addressing Meson build changes for AIX.
We tried to build using below meson
## meson -v
1.6.1

For the following files, the shared_module() function requires specifying the
appropriate symbol import file, which is provided via the aix_link_args
variable:
src/backend/jit/llvm/meson.build
src/backend/replication/libpqwalreceiver/meson.build
src/backend/replication/pgoutput/meson.build
src/backend/snowball/meson.build
src/backend/utils/mb/conversion_procs/meson.build

Additionally, with the latest version of Meson, when building static libraries,
the library file name must be suffixed with “_static” in the following files:
src/interfaces/ecpg/compatlib/meson.build
src/interfaces/ecpg/ecpglib/meson.build
src/interfaces/ecpg/pgtypeslib/meson.build
src/interfaces/libpq/meson.build

Main AIX changes patch - 0001-Changes-to-add-support-for-AIX.v9.pg19.patch (previously submitted one)
Meson AIX changes patch - 0001-AIX-changes-for-meson-build.patch

Looking forward to hearing your thoughts on these changes.
Your feedback on these updates is highly valued.

Thanks,
Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 15 Oct 2025 20:15:50 +0200

On 15.10.25 17:58, Srirama Kucherlapati wrote:
> Main AIX changes patch - 0001-Changes-to-add-support-for- 
> AIX.v9.pg19.patch (previously submitted one)
> 

The largest problem I see in this patch set is that you are making 
unexplained changes in src/include/storage/s_lock.h.  The code that you 
are changing does not only affect AIX but also PPC with other operating 
systems.  AFAICT, the change you are proposing does not correspond to 
the commit that removed AIX support.

Maybe the proposed changes are beneficial for other operating systems as 
well.  But in that case, propose this as a separate patch in a separate 
thread, with supporting information (and probably benchmarks in this case).

If not, then you need to find a way to make this work on AIX without 
materially changing the code that exists for already-supported operating 
systems.

---

From: AIX PG user <[email-masked]>
Date: Thu, 16 Oct 2025 15:28:00 +0000

Hi Peter,
Thank you for your comments.

We’ve had a few discussions in the past regarding the changes related to the
spin lock. Some of those conversations stemmed from this thread:
        "https://www.postgresql.org/message-id/95a44be0-b2f8-464a-8984-771d892b1cac%40iki.fi"
The earlier assembly code was generic across the PPC platform. However, based
on previous discussions, we transitioned to using GCC-specific routines to
enhance platform independence and maintain generality.

These are the comments I have added, let me know if you need more info here.
    +/* On PPC, use the compiler provided Built-in functions for atomic memory
    + * exchange operations.
    + */

For reference, here are some benchmark statistics we gathered earlier:
       "https://www.postgresql.org/message-id/CY8PR15MB5602EB54EFE30D4C21F061BEDB722%40CY8PR15MB5602.namprd15.prod.outlook.com"

I'll run some more benchmarking on this sync_lock and submit the results.
Meanwhile, it would be helpful if you and your team could take a look at the remaining changes.

Thank you,
Sriram.

The new status of this patch is: Needs review

---

From: AIX PG user <[email-masked]>
Date: Wed, 22 Oct 2025 03:52:39 +0000

Hi Team, 
We look forward to your comments and kindly request you to share your feedback on the proposed changes(in the annotations).
Your input is greatly appreciated and will help us refine the solution while ensuring all aspects are thoughtfully addressed.
Thank you in advance for your time and support.

-Sriram.

---

From: Heikki Linnakangas <[email-masked]>
Date: Fri, 31 Oct 2025 19:33:54 +0200

On 16/10/2025 18:28, AIX PG user wrote:
> diff --git a/src/template/aix b/src/template/aix                                                                                                                           
> new file mode 100644                                                                                                                                                       
> index 00000000000..bfc193348f4                                                                                                                                             
> --- /dev/null                                                                                                                                                              
> +++ b/src/template/aix                                                                                                                                                     
> @@ -0,0 +1,7 @@                                                                                                                                                            
> +# This file is referred for specific flags wrt to AIX build process like                                                                                                  
> +# cflags.                                                                                                                                                                 
> +# src/template/aix                                                                                                                                                        
> +                                                                                                                                                                          
> +# Extra CFLAGS for code that will go into a shared library                                                                                                                
> +# With optimization, the MemSet() and MemSetAlign() perform better.                                                                                                       
> +CFLAGS_SL=" -O2 "                                                                                                                                                         
> --     

This looks weird. Sure, "-O2" makes things faster, but we shouldn't 
force that here. If you want optimizations, you should use pass 
CFLAGS="-O2" or CFLAGS="-O3" to configure. And why the special mention 
of MemSet() and MemSetAlign()?

> @@ -95,6 +97,24 @@ libpostgres.a: postgres
>  
>  endif # win32
>  
> +ifeq ($(PORTNAME), aix)
> +
> +postgres: $(POSTGRES_IMP)
> +	$(CC) $(CFLAGS) $(call expand_subsys,$(OBJS)) $(LDFLAGS) -Wl,-bE:$(top_builddir)/src/backend/$(POSTGRES_IMP) $(LIBS) -Wl,-brtllib -o $@
> +
> +# Linking to a single .o with -r is a lot faster than building a .a or passing
> +# all objects to MKLDEXPORT.
> +#
> +# It looks alluring to use $(CC) -r instead of ld -r, but that doesn't
> +# trivially work with gcc, due to gcc specific static libraries linked in with
> +# -r.
> +$(POSTGRES_IMP): $(OBJS)
> +	ld -r -o SUBSYS.o $(call expand_subsys,$^)
> +	$(MKLDEXPORT) SUBSYS.o . > $@
> +	@rm -f SUBSYS.o
> +
> +endif # aix
> +
>  $(top_builddir)/src/port/libpgport_srv.a: | submake-libpgport

I see there's some references to MAKE_EXPORTS in src/backend/Makefile. 
They seem related to MKLDEXPORT, but we never set MAKE_EXPORTS. Are they 
still needed?

- Heikki

---

From: AIX PG user <[email-masked]>
Date: Mon, 03 Nov 2025 14:46:05 +0000

Hi Heikki, 
Thank you for your feedback.

> of MemSet() and MemSetAlign()?

I have removed these.

> They seem related to MKLDEXPORT, but we never set MAKE_EXPORTS. Are they 

If MAKE_EXPORTS is not being used by any platforms other than AIX, we can
consider removing it. However, I’m not entirely certain whether it might still
be required elsewhere.  Since these changes appear to be general and not
strictly AIX-specific, would it be fine to submit them as a separate
patch?

Looking forward to your continued support and guidance.

- Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 7 Nov 2025 17:28:13 +0100

> src/interfaces/libpq/meson.build

It is not going to be acceptable to sprinkle this much AIX-specific code 
around.  Those changes to the meson.build files were not needed before 
AIX support was removed.  You should find a way to do it without these 
changes.

The changes in src/include/port/aix.h in your patch don't make sense. 
This indicates that you are doing something wrong in your local builds. 
Please fix that.

---

From: AIX PG user <[email-masked]>
Date: Mon, 10 Nov 2025 17:00:13 +0000

Hi Peter,
>> Those changes to the meson.build files were not needed before

The change was necessary to ensure that the import file used during the static
PostgreSQL library build begins with the required #! directive and includes the
correct symbol references from the object files. This structure is essential
for compatibility with AIX's linking behaviour, which relies on explicitly
defined symbol import files during static linking. Without this adjustment, the
build process may fail or result in incomplete symbol resolution, particularly
on AIX systems. By aligning the import file format and symbol inclusion with
platform-specific requirements.

We referred to previously removed code that handled similar logic and found it
to be effective. Based on this, we plan to revert the changes in the affected
files and proceed with a more robust solution.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b16bb8776bb834eb1ef8204ca95dd7667ab948b#patch11

Regarding the archiving of shared and static libraries, the latest version of
Meson raises a conflict as both targets have the same name. This issue
arises because, on AIX, both shared and static libraries are named as same
archive, which leads to naming collisions during the build process. We
would still need the below changes.

src/interfaces/ecpg/compatlib/meson.build
src/interfaces/ecpg/ecpglib/meson.build
ecpglib_st = static_library(libname,
src/interfaces/ecpg/pgtypeslib/meson.build
	ecpg_pgtypes_st = static_library(libname,
src/interfaces/libpq/meson.build
	libpq_st = static_library(libname

>> This indicates that you are doing something wrong in your local builds.

We had to do these changes in the src/include/c.h, 
As the MACROS, are getting undefined by the below sys header files.

We made changes to src/include/c.h because certain macros were being 
undefined by the system header files listed below. To address this issue, 
we introduced updates in aix.h.
+#ifndef PGDLLIMPORT +#define PGDLLIMPORT

#include <stdio.h> 
#include <stdlib.h> 
#include <string.h>

We are continuing to analyze the impact of these changes and will refine 
the solution as needed. Once finalized, we will submit the updated changes accordingly.

-Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 9 Dec 2025 16:50:40 +0000

Hi Team, (Peter/Heikki)

I have implemented the requested modifications in the latest patch. Below are the key technical updates:

• Meson Build Configuration: Adjusted below meson.build scripts to incorporate the suggested changes, ensuring proper dependency resolution and improved build consistency.

    Removed the AIX changes in the below from the previous patch.

    Added the static_library() changes.

• CFLAGS Optimization Removal: Removed high-level optimization flags from CFLAGS to prevent unpredictable behaviour and maintain stability during compilation.

I would greatly appreciate it if you could review the patch and share your feedback or any additional recommendations.

Apologies for the delayed response; I was occupied with other tasks.

Your insights are greatly appreciated and will help enhance the patch.

Warm regards,
-Sriram.

---

From: Heikki Linnakangas <[email-masked]>
Date: Tue, 9 Dec 2025 23:00:28 +0200

On 09/12/2025 18:50, Srirama Kucherlapati wrote:
> @@ -1766,9 +1785,9 @@ endforeach
>  # any types wider than 64 bits, as allowing MAXIMUM_ALIGNOF to exceed 8
>  # would be too much of a penalty for disk and memory space.
>  alignof_double = cdata.get('ALIGNOF_DOUBLE')
> -if cc.alignment('int64_t', args: test_c_args, prefix: '#include <stdint.h>') > alignof_double
> -  error('alignment of int64_t is greater than the alignment of double')
> -endif
> +#if cc.alignment('int64_t', args: test_c_args, prefix: '#include <stdint.h>') > alignof_double
> +#  error('alignment of int64_t is greater than the alignment of double')
> +#endif
>  cdata.set('MAXIMUM_ALIGNOF', alignof_double)
>  
>  cdata.set('SIZEOF_LONG', cc.sizeof('long', args: test_c_args))

This is unfinished.

> @@ -1820,7 +1839,7 @@ if cc.links('''
>    if not meson.is_cross_build()
>      r = cc.run('''
>      /* This must match the corresponding code in c.h: */
> -    #if defined(__GNUC__)
> +    #if defined(__GNUC__) || defined(__IBMC__)
>      #define pg_attribute_aligned(a) __attribute__((aligned(a)))
>      #elif defined(_MSC_VER)
>      #define pg_attribute_aligned(a) __declspec(align(a))

There's a comment right there that it must match the corresponding code 
in c.h, but you didn't modify c.h.

> +  # Native memset() is faster, tested on:
> +  memset_loop_limit = 0

Incomplete sentence: tested on what?

We talked about this before. I'm reluctant to have a special case for 
AIX, because I suspect this has little to do with the operating system, 
and more with the compiler and the CPU architecture. I could be wrong; 
maybe the libc memset() implementation on AIX is superior to that on 
linux, for example. I'd love to see thorough performance testing of 
MemSetAligned() vs memset() on common combinations of CPUs and libc 
implementations.  Ideally, we can just replace MemSetAligned() with 
memset() everywhere.

If you do such testing, please start a separate thread for that. On this 
thread, it will get lost with all the AIX-specific stuff.

> +/* This change is required for the meson changes as the autoconf is not run and
> + * to resolve the conflicts in picking the float.h details by default from the
> + * postgres defined datatypes.
> + */
> +#ifdef _AIX
> +#ifndef PGDLLIMPORT
> +#define PGDLLIMPORT
> +#endif  /* PGDLLIMPORT */
> +typedef float float4;
> +typedef double float8;

I don't understand these typedefs. What is the conflict the comment 
talks about?

> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
> +#define pg_noreturn _Noreturn
> +#elif defined(__GNUC__)
> +#define pg_noreturn __attribute__((noreturn))
> +#else
> +#define pg_noreturn
> +#endif

Isn't this just duplicating the snippet in c.h?

> +#include <stdbool.h>

This is in c.h too.

 > src/include/storage/s_lock.h
 > [ switches to __sync_lock_release(lock) on all powerpc systems ]

We talked about this before.

> @@ -18,7 +18,8 @@ GetOptions(
>  
>  if (not(   $format eq 'darwin'
>  		or $format eq 'gnu'
> -		or $format eq 'win'))
> +		or $format eq 'win'
> +        or $format eq 'aix'))
>  {
>  	die "$0: $format is not yet handled (only darwin, gnu, win are)\n";
>  }

Forgot to update the error message.

I didn't review the autoconf / Makefile changes.

> Apologies for the delayed response; I was occupied with other tasks.

Oh no worries, I'm not in any hurry with this. On the contrary to be honest.

- Heikki

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 9 Dec 2025 22:08:39 +0100

On 09.12.25 17:50, Srirama Kucherlapati wrote:
> • Meson Build Configuration: Adjusted below meson.build scripts to 
> incorporate the suggested changes, ensuring proper dependency resolution 
> and improved build consistency.
> 
>      > Regarding the archiving of shared and static libraries, the 
> latest version of
> • CFLAGS Optimization Removal: Removed high-level optimization flags 
> from CFLAGS to prevent unpredictable behaviour and maintain stability 
> during compilation.
> 
> I would greatly appreciate it if you could review the patch and share 
> your feedback or any additional recommendations.
> 

1) In meson.build:

+  cppflags += '-D_GNU_SOURCE'

I don't think this symbol is applicable to AIX.

2) In meson.build:

The comment sentence appears to be truncated.

3) In meson.build:

+#if cc.alignment('int64_t', args: test_c_args, prefix: '#include 
<stdint.h>') > alignof_double
+#  error('alignment of int64_t is greater than the alignment of double')
+#endif

This commented out code cannot be left like this.  Either remove it or 
adjust it as required.

4) In meson.build:

You code does not observe what the comment says.

5) The changes in src/include/port/aix.h are nonsense.  This was 
previously pointed out and you said you would address this.

6) I had previously pointed out that the changes in 
src/include/storage/s_lock.h are not acceptable like that and you had 
said that you would address that.

---

From: "Tristan Partin" <[email-masked]>
Date: Tue, 09 Dec 2025 21:56:14 +0000

Howdy,

Heikki asked me to look at the renames of the static Meson targets. 
I don't understand the reasoning for the changes. I am completely 
unfamiliar with AIX, so maybe it's obvious. Does Meson produce a static 
library and a shared library with the same file extension? If so, why is 
that? That's the only reason I can think of for making those changes. Is 
it AIX-specific or whatever OS you are testing on?

In your patch, I found a link to 
https://www.postgresql.org/message-id/[email-masked]. 

> -> On AIX, you can do a static as well as a dynamic
> -> link against a shared library, it depends on how you
> -> invoke the linker.
> 
> When you link statically, the shared objects from
> the library are added to your executable as required;
> when you link dynamically, only references
> to the shared objects are included in the executable.
> 
> Consequently you do not need a separate static library
> on AIX if you have a dynamic library.

This seems to imply that we don't need a static library at all on AIX. 
However this email is also nearing 20 years old :D. Could we get away 
without the renames on the Meson targets by just not defining the static 
library targets?

-- 
Tristan Partin
Databricks (https://databricks.com)

---

From: Srirama Kucherlapati <[email-masked]>
Date: Wed, 10 Dec 2025 14:31:43 +0000

Hi Tristan,

Thank you for reviewing the patch.

We encountered the following error when building without the "_static" suffix in the library name:
    Found ninja-1.12.1 at /opt/freeware/bin/ninja
    ERROR: Multiple producers for Ninja target "src/interfaces/ecpg/compatlib/libecpg_compat.a”.
    Please rename your targets.

On AIX, shared libraries are archived in a way that allows multiple versions to
coexist within the same archive. This is primarily because shared library(.so)
is archived into .a, which leads to naming conflicts between static and shared
libraries. To address this, we suffixed the library with “_static".

However, we later tested by completely skipping the static library build, and
this approach worked successfully since it eliminates the conflict between
static and shared libraries. I'm working on the changes and will validate
further on this.

BTW, thank you, Heikki and Peter, for your comments. I’m working on the comments

and I’ll keep you updated.

Warm regards,

Sriram.

---

From: "Tristan Partin" <[email-masked]>
Date: Wed, 10 Dec 2025 18:37:02 +0000

> static and shared libraries. I'm working on the changes and will validate

Thanks for the explanation. I'm glad we can workaround this without 
renaming the targets!

---

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 19 Dec 2025 15:34:31 +0000

Hi Peter/Heikki/Tristan

Please find the attached changes for the below comments. Along with comments from Tristan.
Please let me know if these meson specific changes are fine.

0001-Support-for-AIX-meson-updates.pg19.patch - has the changes for the below comments only.
0001-Support-for-AIX-all-meson.pg19.patch - has all the meson specific changes.

>> +  cppflags += '-D_GNU_SOURCE’

    AIX provides certain functions similar to Linux, but with different names and
    signatures. To align them with Linux behaviour, the GNU_SOURCE macro is defined,
    which enables AIX functions to behave like their Linux counterparts.
    You are right, this is not needed for AIX. I have removed and everything got build.

>> The comment sentence appears to be truncated.

    For now, removed this, I’ll provide statistics in a different thread as Heikki suggested.

>> +#if cc.alignment('int64_t', args: test_c_args, prefix: ‘#include
>>+#  error('alignment of int64_t is greater than the alignment of double’)
>> +#endif

>> This commented out code cannot be left like this.  Either remove it or

    I have updated the similar logic as in regular GNU configure file.

>> You code does not observe what the comment says.

    You are right, I have removed this as this is relevant only if we are compiling with XLC. Right now, its compiled with gcc

>> previously pointed out and you said you would address this.

    The changes are irrelevant now, removed them. As all these additional definitions are covered  by the postgres defined header file (src/include/utils/float.h). We can use “_H_FLOAT” to skip the system header "float.h”.

I’d like to finalize all Meson-specific changes first. Meanwhile, I’m also working on the other comments.

Kindly let me know your thoughts and feedback on the changes.

Thanks,

Sriram.

---

From: "Tristan Partin" <[email-masked]>
Date: Sun, 21 Dec 2025 08:19:04 +0000

Thanks for your continued push for AIX support! Here are a few comments:

> # The static libpq is skipped in AIX. This is not required.

For comments like this, I would generally like to see some links or 
inline documentation to why this is the case. Maybe Peter or Heikki 
disagree.

There are a few places in the Meson code like the following:

	if AIX:
		don't define the static library target
	endif

Make sure that the innards of the if statements are indented. 
Alternatively, you could define something like:

	static_library_dependencies = []
	if host_machine.system() == 'AIX'
		# TODO: Document this
		AIX_poison_pill = disabler()
		static_library_dependencies += AIX_poison_pill
	endif

And then for all static library definitions, you would just make sure 
that they all depend on the poison pill. You could document the AIX 
shared/static library situation where the AIX_poison_pill variable is 
defined. I'd like to see if Peter thinks this is a good idea before 
implementing it.

I'm also a little confused by the second patch. Some of it seems to be 
the same, and some other parts seem to be new. Should we consolidate all 
Meson AIX support into one patch? Overall, I think the size of the patch 
is good, and seem pretty maintainable.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Wed, 24 Dec 2025 15:34:13 +0000

Hi Tristan,
Thank you for your feedback and suggestions.

As suggested, we have tried to implement a dependency-driven approach for static library builds, rather than using AIX platform tags.

    modified:   meson.build
        dep_static_lib = declare_dependency()                       << new dependency

        if host_system == 'aix'
            dep_static_lib = disabler()
        endif

    modified:   src/interfaces/ecpg/compatlib/meson.build
        ecpg_compat_st = static_library('libecpg_compat',
          ecpg_compat_sources,
          include_directories: ecpg_compat_inc,
          c_args: ecpg_compat_c_args,
          dependencies: [frontend_stlib_code, thread_dep, dep_static_lib],                       << new dependency
          link_with: [ecpglib_st, ecpg_pgtypes_st],
          kwargs: default_lib_args,
        )

    modified:   src/interfaces/ecpg/ecpglib/meson.build
        ecpglib_st = static_library('libecpg',
          ecpglib_sources,
          include_directories: ecpglib_inc,
          c_args: ecpglib_c_args,
          c_pch: pch_postgres_fe_h,
          dependencies: [frontend_stlib_code, thread_dep, libpq, dep_static_lib],                       << new dependency
          link_with: [ecpg_pgtypes_st],
          kwargs: default_lib_args,
        )

    modified:   src/interfaces/ecpg/pgtypeslib/meson.build
        ecpg_pgtypes_st = static_library('libpgtypes',
          ecpg_pgtypes_sources,
          include_directories: ecpg_pgtypes_inc,
          c_args: ecpg_pgtypes_c_args,
          c_pch: pch_postgres_fe_h,
          dependencies: [frontend_stlib_code, dep_static_lib],                       << new dependency
          kwargs: default_lib_args,
        )

    modified:   src/interfaces/libpq/meson.build
        libpq_st = static_library('libpq',
          libpq_sources,
          include_directories: [libpq_inc],
          c_args: libpq_c_args,
          c_pch: pch_postgres_fe_h,
          dependencies: [frontend_stlib_code, libpq_deps, dep_static_lib],                       << new dependency
          kwargs: default_lib_args,
        )

>  I'd like to see if Peter thinks this is a good idea before implementing it.
Also I would like to understand Peter/Heikki thoughts as well on this new implementation.

> Should we consolidate all Meson AIX support into one patch?
> Overall, I think the size of the patch is good, and seem pretty maintainable.

Thank you, Tristan, for your assistance. At present, the build appears stable

with the recent changes, however, the new dependency is causing impacts

elsewhere(with tmp_install). I will provide the consolidated patch after addressing these concerns.

Thanks,
Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 2 Jan 2026 14:43:00 +0000

Hi Tristan/Peter/Heikki,

Please find attached meson changes wrt to the comments from Tristan regarding the dependency approach.
Kindly let me know your thoughts and suggestions.

Warm regards,
Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 13 Jan 2026 16:06:00 +0000

Hi Tristan, Heikki, Peter,

Greetings!

As suggested, we have addressed all your comments(wrt to meson) and incorporated the dependency-based approach for static libraries in this patch. We believe this solution provides a more generic and maintainable approach.

• Implemented a dependency-driven mechanism for static library builds instead of platform-specific tags.

I kindly request you to review the attached Meson changes based on your earlier feedback. Your input is highly valued and will help us further refine and improve these changes.

Thank you for your time and consideration. I look forward to your valuable feedback.

Warm regards,

Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 14 Jan 2026 22:33:03 +0100

On 13.01.26 17:06, Srirama Kucherlapati wrote:
> As suggested, we have addressed all your comments(wrt to meson) and 
> incorporated the dependency-based approach for static libraries in this 
> patch. We believe this solution provides a more generic and maintainable 
> approach.

This patch appears to be incomplete.  It references a file mkldexport.sh 
but that file does not exist and is not included in the patch.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Thu, 15 Jan 2026 05:51:00 +0000

Hi Peter,
Thank you for taking the time to review this patch.

> but that file does not exist and is not included in the patch.

The initial patch contained only Meson-specific changes addressing the comments provided regarding Meson in this discussion.
https://www.postgresql.org/message-id/DF3QX1B91OKO.182K0IH9QDQUY%40partin.io

As requested, I have now included the mkldexport.sh changes in the attached file. We want to initially close all the meson review comments.

Please review the changes and let me know your thoughts or if any further adjustments are needed.

Looking forward to your feedback.

Warm regards,

Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 21 Jan 2026 15:19:17 +0100

On 15.01.26 06:51, Srirama Kucherlapati wrote:
> The initial patch contained only Meson-specific changes addressing the 
> comments provided regarding Meson in this discussion.
> https://www.postgresql.org/message-id/ 
> DF3QX1B91OKO.182K0IH9QDQUY%40partin.io <https://www.postgresql.org/ 
> message-id/DF3QX1B91OKO.182K0IH9QDQUY%40partin.io>
> 
> As requested, I have now included the mkldexport.sh changes in the 
> attached file. We want to initially close all the meson review comments.
> 

I took this idea of disabling static libraries in meson and made it a 
separate patch; see [0].  It looks like this patch is getting close to 
consensus, so we could commit it soon.  Then you could rebase your patch 
over it, which would make it quite a bit simpler.

I think in general, the meson changes are ok.  But I needed some 
changes, for example, your patch contains

+if not dep_static_lib.disabled()

but the method .disabled() doesn't exist, it should be .found().  So I'm 
wondering how this patch was tested.

Another patch of interest to you could be [1], which moves the 
MAXIMUM_ALIGNOF computation into c.h.  This should also simplify your 
patch.  But that patch has not received any discussion so far.

In any case, you should post complete patch series.  It's ok to split 
changes into multiple patches, and then recommend which parts you want 
reviewed first.  But we need to see at least a rough outline of the 
complete plan before spending significant effort on reviewing the pieces.

[0]: 
https://www.postgresql.org/message-id/e8aa97db-872b-4087-b073-f296baae948d%40eisentraut.org

[1]: 
https://www.postgresql.org/message-id/58cedbc7-5658-468d-868e-a4d06de04ca6%40eisentraut.org

---

From: Srirama Kucherlapati <[email-masked]>
Date: Thu, 22 Jan 2026 16:08:36 +0000

Hi Peter,
Thanks for looking into this and providing your feedback.

> over it, which would make it quite a bit simpler.

That’s a great idea and will definitely help simplify the overall changes.

Once that patch is committed, I’ll rebase my changes accordingly to align with the new approach.

> changes, for example, your patch contains

Thanks for reviewing the changes.

> but the method .disabled() doesn't exist, it should be .found().  So I’m

You’re correct — the method .disabled() doesn’t exist; it should be .found(). We initially tried to follow the same approach used for other dependencies (like docs, docs_pdf, gssapi), and didn’t encounter any errors during testing.

In Meson, the option() class implements disabled(), but the disabler() object does not. When we ran a sample test, we observed that Meson’s behaviour on AIX/Linux seems to ignore any unknown methods. As a result, the .disabled() conditional check was silently skipped, which explains why it didn’t fail during our tests.

> patch.  But that patch has not received any discussion so far.
This is a better approach. This would simplify the changes in both configure and meson.build.

> It's ok to split changes into multiple patches, and then recommend which parts you want
Sure. We are working on the changes. I’ll submit the full patch accordingly.

Thanks again for your guidance and support!

Warm regards,

Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 23 Jan 2026 16:11:25 +0000

Hi Peter,

> complete plan before spending significant effort on reviewing the pieces.
Please find attached patches.
    Meson changes    - 0001-Support-for-AIX-pg19-meson.2.diff
    Complete changes - 0001-Support-for-AIX.pg19.v11.patch

We have updated couple of changes in the full patch wrt to your previous
comments as well. Also, we are working to get the stats for the s_lock.h wrt
TAS. Will submit in a different thread.

Kindly request you to review the meson related changes.

Warm regards,

Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 26 Jan 2026 13:22:04 +0100

> TAS. Will submit in a different thread.

Ok, that patch set looks pretty reasonable now.

Can you confirm that this is the complete patch set required for AIX 
support?

What version of AIX are you testing with?

What compilers are you testing with?

---

From: Srirama Kucherlapati <[email-masked]>
Date: Mon, 26 Jan 2026 14:59:49 +0000

> Ok, that patch set looks pretty reasonable now.

Thank you, Peter, for taking the time to review the patches. I really appreciate your feedback, and it’s great to hear your positive assessment.

> Can you confirm that this is the complete patch set required for AIX support?
Yes, the complete patch attached in the previous mail has all the changes for AIX support.
    Complete changes - 0001-Support-for-AIX.pg19.v11.patch

> What version of AIX are you testing with?
We are testing on an AIX 73F node.
    oslevel - 7300-03-01-2520

> What compilers are you testing with?
We are compiling the source with gcc.
    gcc-12 (GCC) 12.3.0

Warm regards,

Sriram.

---

From: Andres Freund <[email-masked]>
Date: Mon, 26 Jan 2026 10:41:02 -0500

Hi,

>From what I can tell the meson patch *AGAIN* is missing mkldexport.sh. Also,
you seem to reference the script as files('port/aix/mkldexport.sh'), but that
that's not a path that makes sense for our source code structure (nor where
the "complete" patch adds it).

You really need to actually start testing your patches.

Doesn't the meson patch also require the changes to src/tools/gen_export.pl?

On 2026-01-23 16:11:25 +0000, Srirama Kucherlapati wrote:
> diff --git a/meson.build b/meson.build
> index 6e7ddd74683..17ad9c6ca32 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -198,6 +198,8 @@ endif
>  # that purpose.
>  portname = host_system
>
> +dep_static_lib = declare_dependency()

Add a comment saying something like

# In some configurations we don't want to install static libraries. For those
# dep_static_lib can be set to disabler() below.

The introduction of dep_static_lib should be broken out into its own patch.

> +  # This flag is required to make sure the user spefic float.h is
> +  # picked instead of the system float.h header file, which doesnot
> +  # have definition like float8, etc
> +  cflags += '-D_H_FLOAT'

I don't understand this one - how does defining _H_FLOAT lead to a different
header being picked? Also, float8 is defined in c.h, so it hardly could be
influenced by a system float.h header?

Our float.h header is only included as "utils/float.h", so it really shouldn't
be confused with a system header?

> @@ -1765,10 +1793,49 @@ endforeach
>  # as long, char, short, or int.  Note that we intentionally do not consider
> -alignof_double = cdata.get('ALIGNOF_DOUBLE')
> +if host_system != 'aix'
> +  alignof_double = cdata.get('ALIGNOF_DOUBLE')
> +  if cc.alignment('int64_t', args: test_c_args, prefix: '#include <stdint.h>') > alignof_double
> +       error('alignment of int64_t is greater than the alignment of double')
> +  endif
> +else
> +  # The AIX 'power' alignment rules apply the natural alignment of the "first
> +  # member" if it is of a floating-point data type (or is an aggregate whose
> +  # recursively "first" member or element is such a type). The alignment
> +  # associated with these types for subsequent members use an alignment value
> +  # where the floating-point data type is considered to have 4-byte alignment.
> +  # More info
> +  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99557
> +  #
> +  # The double is aligned to 4-bytes on AIX in aggregates. But to maintain
> +  # alignement across platforms the max alignment of long should be considered.

How are these "AIX 'power' alignment rules" for float not just completely
broken?

I assume this means that 4 byte aligned floats work just fine, but have
degraded peformance?

Is there documentation about this that isn't an already fixed bug report in gcc?

Maybe I'm confused, but doesn't this power alignment rule mean that the
cc.alignment('double') will always return 8? That computation won't apply the
"subsequent member" rule, and therefore will have an alignment of 8. Which in
turn seems to make this entire change pointless?

> +  # Get the alignment values
> +  ac_cv_alignof_long    = cc.alignment('long', args: test_c_args, prefix: '#include <stdint.h>')
> +  ac_cv_alignof_double  = cc.alignment('double', args: test_c_args, prefix: '#include <stdint.h>')
> +  ac_cv_alignof_int64_t = cc.alignment('int64_t', args: test_c_args, prefix: '#include <stdint.h>')

I've previously complained about these av_cv_ variable names. This isn't
autoconf. What is this doing here?

Why do we need a platform specific alignment determination for long, int64?

> +  message('Alignment of long    : @0@'.format(ac_cv_alignof_long))
> +  message('Alignment of double  : @0@'.format(ac_cv_alignof_double))
> +  message('Alignment of int64_t : @0@'.format(ac_cv_alignof_int64_t))

These are already going to be output by cc.alignment, this is just redundant,
no?

> +  # Start with long
> +  alignof_double = ac_cv_alignof_long
> +  message('MAX ALIGN ac_cv_alignof_long')
> +
> +  # Compare with double
> +  if alignof_double < ac_cv_alignof_double
> +    alignof_double = ac_cv_alignof_double
> +    message('MAX ALIGN ac_cv_alignof_double')
> +  endif
> +
> +  # Compare with int64_t
> +  if alignof_double < ac_cv_alignof_int64_t
> +    alignof_double = ac_cv_alignof_int64_t
> +    message('MAX ALIGN ac_cv_alignof_int64_t')
> +  endif
> +endif
> +message('MAX ALIGN OF DOUBLE : @0@'.format(alignof_double))

This is a lot of output for something that's just computing a maximum of three
variables.

> diff --git a/src/backend/meson.build b/src/backend/meson.build
> index b831a541652..4838f245ab3 100644
> --- a/src/backend/meson.build
> +++ b/src/backend/meson.build
> @@ -125,6 +125,24 @@ if host_system == 'windows'
>      '--FILEDESC', 'PostgreSQL Server',])
>  endif
>
> +if host_system == 'aix'
> +  # The '.' argument leads mkldexport.sh to emit "#! .", which refers to the
> +  # main executable, allowing extension libraries to resolve their undefined
> +  # symbols to symbols in the postgres binary.
> +  postgres_imp = custom_target('postgres.imp',
> +    command: [files('port/aix/mkldexport.sh'), '@INPUT@', '.'],
> +    input: postgres_lib,
> +    output: 'postgres.imp',
> +    capture: true,
> +    install: true,
> +    install_dir: dir_lib,
> +    build_by_default: false,
> +  )
> +  backend_link_args += '-Wl,-bE:@0@'.format(postgres_imp.full_path())
> +  backend_link_depends += postgres_imp
> +endif

This should be moved next to the msvc specific block (the one about
postgres_def) and should use an elif.

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Mon, 26 Jan 2026 12:45:37 -0500

> What compilers are you testing with?

I tried to build HEAD with 0001-Support-for-AIX.pg19.v11.patch
on the GCC compile farm (cfarm119.cfarm.net, which is running
AIX 7.3); I used gcc 13.3.0.  I observed the following problems:

* The patch's changes to configure do not match those to configure.ac.
I used configure as-patched, so I don't know if it'd work after
re-running autoconf.

* In my tree, mkldexport.sh was created without execute permissions,
causing a build failure.  I see that the patch says
	new file mode 100755
so this is arguably the fault of the rather hoary version of
patch(1) that cfarm119 has.  I mention it mainly to remind the
eventual committer to make sure mkldexport.sh is committed with
the correct permissions.

* I got this:

In file included from ../../../../src/include/postgres.h:48,
                 from pgstat_slru.c:18:
pgstat_slru.c:60:11: warning: no previous prototype for 'pgstat_count_slru_truncate64' [-Wmissing-prototypes]
   60 | CppConcat(pgstat_count_slru_,stat)(int slru_idx)        \
      |           ^~~~~~~~~~~~~~~~~~
../../../../src/include/c.h:429:41: note: in definition of macro 'CppConcat'
  429 | #define CppConcat(x, y)                 x##y
      |                                         ^
pgstat_slru.c:84:1: note: in expansion of macro 'PGSTAT_COUNT_SLRU'
   84 | PGSTAT_COUNT_SLRU(truncate)
      | ^~~~~~~~~~~~~~~~~

and then

ld: 0711-317 ERROR: Undefined symbol: .pgstat_count_slru_truncate

On investigation, this is happening because <unistd.h> has

	#define   truncate        truncate64

which causes "PGSTAT_COUNT_SLRU(truncate)" to expand as
"pgstat_count_slru_truncate64", which is not the name declared in
pgstat.h.  An even more unfortunate result is that the "truncate"
field in PgStat_SLRUStats might actually be named "truncate64",
depending on whether <unistd.h> was read before pgstat.h.

I got around that by partially reverting eccba079c2ea:

diff --git a/src/backend/utils/activity/pgstat_slru.c b/src/backend/utils/activity/pgstat_slru.c
index 2190f388eae..4d8ad3f20fc 100644
--- a/src/backend/utils/activity/pgstat_slru.c
+++ b/src/backend/utils/activity/pgstat_slru.c
@@ -81,7 +81,11 @@ PGSTAT_COUNT_SLRU(blocks_written)
 PGSTAT_COUNT_SLRU(flush)
 
 /* pgstat_count_slru_truncate */
-PGSTAT_COUNT_SLRU(truncate)
+void
+pgstat_count_slru_truncate(int slru_idx)
+{
+       get_slru_entry(slru_idx)->truncate += 1;
+}

I didn't have to make any other changes, so it seems that we are
currently consistent about always reading <unistd.h> first, but this
seems terribly fragile.  We probably need some more-invasive answer,
like changing both the function and field name to "trunc" or something
like that.

* I also got some warnings:

auth.c: In function 'auth_peer':
auth.c:1877:13: warning: implicit declaration of function 'getpeereid' [-Wimplicit-function-declaration]
 1877 |         if (getpeereid(port->sock, &uid, &gid) != 0)

pg_locale_libc.c: In function 'wchar2char':
pg_locale_libc.c:1243:26: warning: implicit declaration of function 'wcstombs_l'; did you mean 'wcstombs'? [-Wimplicit-function-declaration]
 1243 |                 result = wcstombs_l(to, from, tolen, loc);

fe-connect.c: In function 'PQconnectPoll':
fe-connect.c:3598:45: warning: implicit declaration of function 'getpeereid'; did you mean 'getpwuid'? [-Wimplicit-function-declaration]
 3598 |                                         if (getpeereid(conn->sock, &uid, &gid) != 0)

These did not break the build (so the functions do exist...) but
they need to be fixed.

After all that I was able to get through "make" and "make install",
but testing failed immediately:

bash-5.3$ initdb
exec(): 0509-036 Cannot load program initdb because of the following errors:
        0509-022 Cannot load module /home/tgl/testversion/lib/libpq.a(libpq.so.5).
        0509-150   Dependent module libgcc_s.a(shr.o) could not be loaded.
        0509-022 Cannot load module libgcc_s.a(shr.o).
        0509-026 System error: A file or directory in the path name does not exist.

So there's something wrong with the make rules for using libpq.so.
I do not know anything about AIX, so I can't debug this.

I was unable to test the meson patches, because meson isn't installed
on this machine.

I haven't actually read the patch, so don't take this as an
endorsement of the changes otherwise.

			regards, tom lane

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 27 Jan 2026 16:21:12 +0000

Hi Tom,
We have tested this patch on our environment, and we see all the basic tests are passing and Postgres binary is up.

ok 226       + eager_aggregate                           921 ms
# parallel group (2 tests):  oidjoins event_trigger
ok 227       + oidjoins                                  199 ms
ok 228       + event_trigger                             255 ms
ok 229       - event_trigger_login                        55 ms
ok 230       - fast_default                              207 ms
ok 231       - tablespace                                533 ms
1..231
# All 231 tests passed.

We have set the below flags for building the source

export OBJECT_MODE=64
export FLAG64="-maix64"
export CC__=/opt/freeware/bin//gcc-12
export CXX__=/opt/freeware/bin//g++-12
export CC64="${CC__}"
export CFLAGS="${FLAG64} -O2 "
export GLOBAL_CC_OPTIONS="-O2"
export CC="${CC64} "
export LDFLAGS="-L/opt/freeware/lib64 -L/usr/lib64 -L/opt/freeware/lib -L/usr/lib -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib"
export LDFLAGS=$LDFLAGS:/opt/freeware/lib64/perl5/5.38/CORE/:
export PYTHON=/opt/freeware/bin/python3.9
export AR='/usr/bin/ar -X64’

The patch is build on top of this commit, which is older
      commit c581c9a7ac2af2c75567013f25125bd294d49ff2

We are trying to integrate the changes to the latest HEAD
I would like to know if there are any specific environment variables are set on your build machine.

Warm regards,

Sriram.

---

From: Tom Lane <[email-masked]>
Date: Tue, 27 Jan 2026 15:26:38 -0500

> export AR='/usr/bin/ar -X64’

Ouch.  Our normal expectation is that you can build a working
Postgres with nothing more complicated than

	./configure && make && make install

(well, maybe you want a nondefault --prefix and some feature
options, but getting to a working executable shouldn't take
much more than that).  It's totally not okay to expect users
to preset a bunch of environment variables, especially not if
that requirement appears nowhere in the documentation.

So one TODO item for your patch is to restore (and update)
the AIX-specific portions of the documentation, particularly
the build instructions.  But I do not want to see anything as
messy as the above in the build instructions.

After re-reading what used to be in installation.sgml, I'm inclined
to suggest that we just say that only 64-bit builds using gcc are
supported on AIX.  Surely the number of users still wanting 32-bit
Postgres on AIX is indistinguishable from zero.  Then we could remove
the documentation about likely failure modes of a 32-bit build.
(Also, perhaps we could bake the bits about OBJECT_MODE=64 and -maix64
into the autoconf/meson logic and not burden users with dealing with
those?)

After some digging, I realized that the cause of my build failure with
not finding libgcc_s.a was that you'd removed this stanza that
Makefile.aix used to have:

# when building with gcc, need to make sure that libgcc can be found
ifeq ($(GCC), yes)
libpath := $(libpath):$(dir $(shell gcc -print-libgcc-file-name))
endif

I don't really understand how it works for you without that.
I suppose that your explicit setting of LDFLAGS masked the problem,
but doing that did not work for me, which I found was because our
rpath logic overrides any externally-given -Wl,-blibpath setting.
Were you perhaps building with --disable-rpath?  In any case, manually
putting every required directory into LDFLAGS is not sustainable.
There's a reason our makefiles work so hard to build that list
automatically.

In any case, once I put back the missing Makefile.aix bit, I was
able to get a working 64-bit build after doing what installation.sgml
used to tell people:

     For a 64-bit build, set <envar>OBJECT_MODE</envar> to 64 and
     pass <literal>CC="gcc -maix64"</literal>
     to <command>configure</command>.

(It also said to set LDFLAGS="-Wl,-bbigtoc", but that doesn't
seem to be necessary anymore?)

However, my build doesn't pass the core regression tests.  There
is one failure in float8.out, which on investigation is because
lgamma(NaN) is failing (returning ERANGE) instead of silently
returning NaN.  That behavior is directly contradictory to what
"man lgamma" says, so I guess they fixed it in recent AIX, but we
probably need a workaround for AIXen that are still in the field.
cfarm119 is running a just slightly back-rev AIX:
$ oslevel -s
7300-01-02-2320

With the patch attached, I can get through "make installcheck".
However, I'm unable to attempt "make check-world" because
src/test/modules/test_cplusplusext doesn't compile:

g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2  -fvisibility=hidden -fvisibility-inlines-hidden -I. -I. -I../../../../src/include     -c -o test_cplusplusext.o test_cplusplusext.cpp
In file included from ../../../../src/include/c.h:57,
                 from ../../../../src/include/postgres.h:48,
                 from test_cplusplusext.cpp:18:
../../../../src/include/pg_config.h:588:24: error: expected unqualified-id before '__int128'
  588 | #define PG_INT128_TYPE __int128
      |                        ^~~~~~~~
../../../../src/include/c.h:580:9: note: in expansion of macro 'PG_INT128_TYPE'
  580 | typedef PG_INT128_TYPE int128
      |         ^~~~~~~~~~~~~~
../../../../src/include/pg_config.h:588:24: error: expected unqualified-id before '__int128'
  588 | #define PG_INT128_TYPE __int128
      |                        ^~~~~~~~
../../../../src/include/c.h:586:18: note: in expansion of macro 'PG_INT128_TYPE'
  586 | typedef unsigned PG_INT128_TYPE uint128
      |                  ^~~~~~~~~~~~~~
make: *** [<builtin>: test_cplusplusext.o] Error 1
      |                  ^~~~~~~~~~~~~~
make[5]: *** [<builtin>: test_cplusplusext.o] Error 1

I poked at trying to fix that, without success.  This is a
reasonably late-model g++:

$ g++ --version
g++ (GCC) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

so I don't know why it doesn't like __int128.  This is very new code,
so there may be a non-AIX-specific issue for us to fix.  (But I
could not reproduce the issue on the nearest version I have at hand,
g++ (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7)
from Fedora 38.)

Another thing I noticed: ps status isn't working.  (All the postmaster
child processes look the same in "ps auxww".)  I suppose you need to
restore the AIX support in ps_status.c.

FWIW, attached is a delta patch showing where I am now (on top of
your v11 patch and the pgstat_slru.c hack I showed earlier).

			regards, tom lane

diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index b5a7c57e53a..641e7de21a0 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -2852,6 +2852,12 @@ dlgamma(PG_FUNCTION_ARGS)
 	float8		arg1 = PG_GETARG_FLOAT8(0);
 	float8		result;
 
+	/* On some versions of AIX, lgamma(NaN) fails with ERANGE */
+#if defined(_AIX)
+	if (isnan(arg1))
+		PG_RETURN_FLOAT8(arg1);
+#endif
+
 	/*
 	 * Note: lgamma may not be thread-safe because it may write to a global
 	 * variable signgam, which may not be thread-local. However, this doesn't
diff --git a/src/makefiles/Makefile.aix b/src/makefiles/Makefile.aix
index e91b250fd19..d8d8a4d68b0 100644
--- a/src/makefiles/Makefile.aix
+++ b/src/makefiles/Makefile.aix
@@ -6,8 +6,11 @@
 # -blibpath must contain ALL directories where we should look for libraries
 libpath := $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -e's/ //g'):/usr/lib:/lib
 
-# AIX uses a stricter, more explicit approach. The runtime linker expects
-# to tell it exactly where to look using -blibpath.
+# when building with gcc, need to make sure that libgcc can be found
+ifeq ($(GCC), yes)
+libpath := $(libpath):$(dir $(shell gcc -print-libgcc-file-name))
+endif
+
 rpath = -Wl,-blibpath:'$(rpathdir)$(libpath)'
 
 # gcc needs to know it's building a shared lib, otherwise it'll not emit

---

From: Tom Lane <[email-masked]>
Date: Tue, 27 Jan 2026 16:42:35 -0500

... btw, I was annoyed to notice that AIX still does this in
64-bit builds:

checking size of void *... 8
checking size of size_t... 8
checking size of long... 8
checking size of long long... 8
checking size of intmax_t... 8
checking alignment of short... 2
checking alignment of int... 4
checking alignment of long... 8
checking alignment of int64_t... 8
checking alignment of double... 4

Normally we reject alignof(double) < alignof(int64), for the reasons
explained in configure.ac:

# We require 'double' to have the strictest alignment among the basic types,
# because otherwise the C ABI might impose 8-byte alignment on some of the
# other C types that correspond to TYPALIGN_DOUBLE SQL types.  That could
# cause a mismatch between the tuple layout and the C struct layout of a
# catalog tuple.  We used to carefully order catalog columns such that any
# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.

I see that your patch summarily overrides that restriction (without
bothering to touch this comment), but I fear that the chances of
that being acceptable as-is are zero.  We're not going to go back to
having to count bytes every time we change a system catalog rowtype
that involves an 'int8' or 'float8' column.

I think the only way we could deal with this in a maintainable
fashion would be to remove the assumption that int64 and double
have the same alignment requirement.  That is tech debt that
we really should have cleaned up years ago anyway.  The main
thing that's discouraged people from pursuing it is the fear
of adding overhead to tuple assembly/disassembly loops.  But
I think maybe we could avoid adding such overhead by mapping
two different type alignment symbols at the source-code level
into appropriate values at runtime.  Or a bunch of conditional
compilation, or whatever.  Any modern machine is going to have
to be able to deal with both 4-byte and 8-byte alignment
requirements, it's just a question of which datatypes have
which requirement.

While I don't foresee that being an enormous patch, it's not trivial
either.  I'd encourage you to write and submit it as a separate patch
rather than something directly tied to the AIX-restoration patch.

			regards, tom lane

---

From: Tom Lane <[email-masked]>
Date: Tue, 27 Jan 2026 16:50:15 -0500

> src/test/modules/test_cplusplusext doesn't compile:

Ah, I figured out that bit: g++ will take this if you specify -maix64
to it too.  The built module would not have worked anyway without
that, since it'd be 32-bit (AFAICT neither gcc nor g++ react to
the OBJECT_MODE environment variable).

It's not exactly clear why gcc will accept __int128 in 32-bit mode
while g++ won't, but that seems like another good reason to decide
that we won't support 32-bit builds on AIX anymore.

			regards, tom lane

---

From: Aditya Kamath <[email-masked]>
Date: Wed, 28 Jan 2026 10:25:41 +0000

Hi Andrew,

Thank you for your review comments for AIX so far.

While we are working on the rest of the comments you had sent here is our explanation for using the  '-D_H_FLOAT’ flag in the source directory meson.build file.

>> +  cflags += '-D_H_FLOAT’

>I don't understand this one - how does defining _H_FLOAT lead to a >different
>header being picked? Also, float8 is defined in c.h, so it hardly could >be

>Our float.h header is only included as "utils/float.h", so it really >shouldn’t

So If we do not use the flag the error we get is as follows,

FAILED: src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o
gcc -Isrc/backend/utils/activity/wait_event_names.a.p -Isrc/include/utils -I../src/include/utils -Isrc/include -I../src/include -I/opt/freeware/include -I/opt/freeware/include/libxml2 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wmissing-prototypes -Wpointer-arith -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -Wdeclaration-after-statement -Wno-format-truncation -Wno-stringop-truncation -maix64 -fPIC -pthread -DBUILDING_DLL1233 -MD -MQ src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o -MF src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o.d -o src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o -c ../src/backend/utils/activity/wait_event_funcs.c
In file included from /usr/include/sys/limits.h:307,
                 from /opt/freeware/lib/gcc/powerpc-ibm-aix7.3.0.0/13/include-fixed/stdio.h:589,
                 from ../src/include/c.h:65,
                 from ../src/include/postgres.h:48,
                 from ../src/backend/utils/activity/wait_event_funcs.c:15:
../src/include/utils/float.h:28:19: error: expected ';' before 'int'
   28 | extern PGDLLIMPORT int extra_float_digits;
../src/include/utils/float.h:289:37: error: unknown type name 'float4'
  289 | float4_min(const float4 val1, const float4 val2)
../src/include/utils/float.h:294:15: error: unknown type name 'float8'
  294 | static inline float8

The reason this happened is because -I../src/include/utils argument in the command included the float.h header first before the ./src/include/c.h header of postgresql which actually has the
PGDLLIMPORT, float4 and float8 definitions.

So, the header files have mismatched in the order they are processed. If we eliminate -I../src/include/utils in the command, then it will work.

But that will not happen automatically since we use include_directories() everywhere which adds both the source and the build directory includes. If we can get meson to not use
-I../src/include/ in AIX while including headers we will be able to compile.

We are currently experimenting with implicit_include_directories from the document below to see if we can remove the same
https://mesonbuild.com/Include-directories.html.

Reason for -D_H_FLOAT

This prevents AIX libc’s float.h to be included via c.h -> stdio.h -> limits.h -> float.h. The real problem is header include order in AIX. Compiler sees src/include/utils/float.h first and then c.h. This is a problem. When this flag is set, AIX’s float.h is skipped causing system header include chain to change. AIX no longer injects float.h early which results in c.h included before utils/float.h. the way Postgres expects.

Let us know what you think.

Is there a preferred or cleaner way you know to ensure the correct include ordering like using implicit_include_directories so that utils/float.h is not included before c.h?

Have a nice day ahead.

Thanks and regards,
Aditya.

From: Srirama Kucherlapati <[email-masked]>
Date: Wednesday, 28 January 2026 at 9:34 AM
To: Aditya Kamath <[email-masked]>
Subject: FW: [EXTERNAL] Re: AIX support

FYI

Warm regards,

Sriram.

------------------------------------------

VIOS/SSP Development,

ISDL, IBM India Pvt Ltd.

From: Andres Freund <[email-masked]>
Date: Monday, 26 January 2026 at 21:11
To: Srirama Kucherlapati <[email-masked]>
Cc: Peter Eisentraut <[email-masked]>, [email-masked] <[email-masked]>, Heikki Linnakangas <[email-masked]>, Tristan Partin <[email-masked]>, AIX PG user <[email-masked]>
Subject: [EXTERNAL] Re: AIX support

Hi,

Greetings,

Andres Freund

---

From: Aditya Kamath <[email-masked]>
Date: Wed, 28 Jan 2026 15:20:25 +0000

Hi Andres,

I can explain this differently as well.

We know that include_directories property in meson will include the source and the build directory in the command. Ex: If we give “src/include” then “-Isrc/include” and “-I../src/include” are added.

>header being picked?

Below is the error message we get in AIX if we do not use '-D_H_FLOAT’
FAILED: src/backend/utils/activity/wait_event_names.a.p/wait_event_funcs.c.o
gcc -Isrc/backend/utils/activity/wait_event_names.a.p -Isrc/include/utils -I../src/include/utils -Isrc/include -I../src/include -I/opt/freeware/include -I/opt/freeware/include/libxml2 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wmissing-prototypes -Wpointer-arith -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -Wdeclaration-after-statement -Wno-format-truncation -Wno-stringop-truncation -maix64 -fPIC -pthread -DBUILDING_DLL1233 -MD -MQ
./src/include/utils/float.h:28:19: error: expected ';' before 'int'
   28 | extern PGDLLIMPORT int extra_float_digits;

There is a clear missing of float.h definitions, the reason being float.h got included before "src/include/c.h”.

Kindly observe the command  "-I../src/include/utils” flag came in the front.

Now in c.h when stdio.h is called in AIX at line 65, then AIX system limits.h is called and then within that AIX system float.h is called.

But here is the catch. It won’t pick the AIX system float.h. It will pick the Postgres "src/include/utilsfloat.h”.

The reason being the compiler is designed to pick what comes first in -I flag. One proof of that is here. https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html

I am assuming all systems behave like this.

This is the root cause of the problem. That "-I../src/include/utils” which meson adds.

So now "src/include/utils/float.h”.is picked up first even before "src/include/c.h”.

That is why we saw the error. When we define “_H_FLOAT” we essentially force the system header to be ignored in the system limits.h where it is called and then the Postgres  "src/include/utils/float.h” takes over.

Hope this explains Andres.

There are multiple things we can do here.

One being define “_H_FLOAT”

The other being use  #include_next float.h under ifdef _AIX guard

The third we are experimenting is to have implicit_include_directories: false as per document here https://mesonbuild.com/Include-directories.html, but that might difficult since recursive include directories exists in Postgres.

Kindly let us know if this explanation helps and what you think. Also If there is a preferred or cleaner way you know let us know.

Have a nice day ahead.

Thanks and regards,

Aditya.

From: Aditya Kamath <[email-masked]>
Date: Wednesday, 28 January 2026 at 3:55 PM
To: Srirama Kucherlapati <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [EXTERNAL] Re: AIX support

Hi Andrew,

Reason for -D_H_FLOAT

Have a nice day ahead.

Thanks and regards,
Aditya.

FYI

Warm regards,

Sriram.

VIOS/SSP Development,

ISDL, IBM India Pvt Ltd.

Hi,

Greetings,

Andres Freund

---

From: Robert Haas <[email-masked]>
Date: Wed, 28 Jan 2026 10:25:58 -0500

> You really need to actually start testing your patches.

+1. The quality of the patches posted to this thread is very
noticeably lower than what we typically expect or accept. They are
missing files, or they don't work, or the changes are not properly
explained, or they do things that are clearly unlike anything else we
do anywhere in the source tree, or they change how things work for
other platforms rather than just being AIX-specific, or they don't
work unless you follow a bunch of undocumented steps, or whatever the
case may be.

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

---

From: Robert Haas <[email-masked]>
Date: Wed, 28 Jan 2026 10:41:52 -0500

> But here is the catch. It won’t pick the AIX system float.h. It will pick the Postgres "src/include/utilsfloat.h”.

PostgreSQL's header should always be included as "utils/float.h" and
the system header should always be included as "float.h" (or, well,
<float.h>, presumably). So this confusion should not exist unless the
include paths are messed up. It doesn't seem correct to me that the
include path includes src/include/utils rather than just src/include,
but I see the same thing here:

    "command": "ccache clang
-Isrc/backend/utils/activity/wait_event_names.a.p -Isrc/include/utils
-I../pgsql/src/include/utils -Isrc/include -I../pgsql/src/include
-I/opt/local/include -I/opt/local/include/libxml2
-I/opt/local/libexec/openssl3/include -fdiagnostics-color=always -Wall
-Winvalid-pch -O2 -g -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk
-fno-strict-aliasing -fwrapv -fexcess-precision=standard
-Wmissing-prototypes -Wpointer-arith -Werror=vla
-Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -Wcast-function-type -Wformat-security
-Wdeclaration-after-statement -Wmissing-variable-declarations
-Wno-unused-command-line-argument -Wno-compound-token-split-by-macro
-Wno-format-truncation -Wno-cast-function-type-strict -DBUILDING_DLL
-MD -MQ src/backend/utils/activity/wait_event_names.a.p/wait_event.c.o
-MF src/backend/utils/activity/wait_event_names.a.p/wait_event.c.o.d
-o src/backend/utils/activity/wait_event_names.a.p/wait_event.c.o -c
../pgsql/src/backend/utils/activity/wait_event.c",

which happens because of:

wait_event = static_library('wait_event_names',
  waitevent_sources,
  dependencies: [backend_code],
  include_directories: include_directories('../../../include/utils'),
  kwargs: internal_lib_args,
)

which happens because wait_event_funcs.c contains:

#include "wait_event_funcs_data.c"

and for some reason, that file gets placed in src/include/utils.

The attached patch, which also adjusts wait_events.c, fixes it for me.

This is kind of a good example of how you are not pursuing your goals
here in the best way possible. The issue here is legitimate, in the
sense that including src/include/utils in the include path for some
file doesn't seem legit to me. But fixing that problem by defining,
just on AIX, the same symbol that the system header defines seems like
clearly the wrong fix. What if we needed to include the actual float.h
somewhere? What if the problem also occurred on some other platform?
Please put a bit more thought into the right ways to (1) describe the
things you find to us and (2) fix them.

Thanks,

---

From: Andres Freund <[email-masked]>
Date: Wed, 28 Jan 2026 12:33:01 -0500

Hi,

> but I see the same thing here:

I agree that this is wrong.

CCing Michael and Bertrand, they added this in fa88928470b5 and 1e68e43d3f0f.

> and for some reason, that file gets placed in src/include/utils.

The reason for that is that the same invocation also generates
wait_event_types.h, which is included by other headers.

> The attached patch, which also adjusts wait_events.c, fixes it for me.

Unfortunately I suspect that'll cause issues with make builds, because there
the files are generated in a different place (src/backend/activity) and then
only wait_event_types.h is copied to src/include. So including the files as
utils/ won't work.

I'd fix that aspect by doing the same thing in the autoconf build as we do in
meson, i.e. keep the file in the include dir. We already do that e.g. for
guc_tables.inc.c, see this src/backend/utils/Makefile stanza:

# These generated headers must be symlinked into src/include/.
# We use header-stamp to record that we've done this because the symlinks
# themselves may appear older than fmgr-stamp.
$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h probes.h guc_tables.inc.c
	cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h probes.h guc_tables.inc.c; do \
	  rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \
	done
	touch $@

Alternatively: I'm not a fan of including .c files that are not actually
working C.  You could just make wait_event_funcs_data.c be a complete C file,
defining waitEventData, that is then built as a standalone file.

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Wed, 28 Jan 2026 20:36:37 -0500

I wrote:
> we really should have cleaned up years ago anyway.

In hopes of moving this effort along, I've posted a draft patch
for that part here:

https://www.postgresql.org/message-id/1127261.1769649624%40sss.pgh.pa.us

We are running out of time to make this happen for v19, so
I suggest focusing your effort if you don't want to see
AIX support slide for another year.

			regards, tom lane

---

From: Srirama Kucherlapati <[email-masked]>
Date: Thu, 29 Jan 2026 03:43:06 +0000

> In hopes of moving this effort along, I've posted a draft patch

Thanks Tom, for your support and suggestions we are working on the addressing the review comments. I will integrate the patch with our changes and will update you.

Warm regards,

Sriram.

---

From: Michael Paquier <[email-masked]>
Date: Fri, 30 Jan 2026 08:24:47 +0900

> only wait_event_types.h is copied to src/include. So including the files as

Sorry for the crickets and the delay in replying.

> 	  rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \

Yeah, using this route would be sensible, removing the trick with the
incorrect include dir.  Let me a couple of hours to see if I can sort
out a patch..

Should any of these be backpatched, actually?  Based on the lack of
complaints, it does not seem so to me, but if we are targetting a
backpatch of the AIX port, that would be required.

> defining waitEventData, that is then built as a standalone file.

FWIW, that does not strike me as an issue.  We do some of that already
in src/backend/nodes/ for the switch files.  It comes down to simpler
scripts generating the code.
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Thu, 29 Jan 2026 18:48:37 -0500

> backpatch of the AIX port, that would be required.

There's no plan to backpatch the AIX port ... but if we can clean
up this include-path mess not too invasively, I think it might be
a good idea to back-patch that much.  I'm concerned that confusion
between <float.h> and utils/float.h might be a problem on other
platforms too.

			regards, tom lane

---

From: Michael Paquier <[email-masked]>
Date: Fri, 30 Jan 2026 13:38:42 +0900

> between <float.h> and utils/float.h might be a problem on other

Noted.  Attached is the patch I am finishing with, tested with meson
and configure/make with and without VPATH.  

While looking at the whole object dependency tree in the builds, I
have settled down to a reuse of the same logic as guc_tables.inc.c for
configure/make, by pushing down one level the generation of the three
wait event files.  These are not anymore saved in
src/backend/utils/activity/, just src/backend/utils/, including them
under header-stamp.  Building directly in src/backend/utils/activity/
also works, with two rules in src/backend/utils/activity/Makefile to
force a rebuild.  The files are then included as if they were in
include/utils/, with the generation of links from src/backend/utils/
to src/include/utils/, just like guc_tables.inc.c.  That's the least
invasive method I could come up with.

I have run out of tokens for the CI this month, so I have not been
able to check it there.  My manual tests across all three build
methods are working.
--
Michael
From 08916ab93b47bb87936afce9ae5fcc46dc2070dc Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email-masked]>
Date: Fri, 30 Jan 2026 13:25:29 +0900
Subject: [PATCH] Fix incorrect generation of wait-event files

In a meson build, include/utils was incorrectly listed in the set of
include_directories.  This would conflict with the headers pulled in by
an environment.  This issue has not been an issue in the buildfarm; it
has been noted with AIX and a conflict with float.h.

Combo oversight in fa88928470b5 and 1e68e43d3f0f.

blah, blah..

Discussion: https://postgr.es/m/vua2n6svb6fac3fmz42ahqxndmgbgor7vpxtemis5evasfpzb3@ogs4ewexkpjm
Backpatch-through: 17
---
 src/include/Makefile                          |  1 +
 src/include/utils/.gitignore                  |  2 ++
 src/backend/Makefile                          | 10 +---------
 src/backend/utils/.gitignore                  |  3 +++
 src/backend/utils/Makefile                    | 13 ++++++++++---
 src/backend/utils/activity/.gitignore         |  3 ---
 src/backend/utils/activity/Makefile           | 17 ++++-------------
 src/backend/utils/activity/meson.build        |  1 -
 src/backend/utils/activity/wait_event.c       |  2 +-
 src/backend/utils/activity/wait_event_funcs.c |  2 +-
 10 files changed, 23 insertions(+), 31 deletions(-)
 delete mode 100644 src/backend/utils/activity/.gitignore

diff --git a/src/include/Makefile b/src/include/Makefile
index 4ef060e90503..ac673f4cf17b 100644
--- a/src/include/Makefile
+++ b/src/include/Makefile
@@ -105,6 +105,7 @@ uninstall:
 
 clean:
 	rm -f utils/fmgroids.h utils/fmgrprotos.h utils/guc_tables.inc.c utils/errcodes.h utils/header-stamp
+	rm -f utils/pgstat_wait_event.c utils/wait_event_funcs_data.c
 	rm -f storage/lwlocknames.h utils/probes.h utils/wait_event_types.h
 	rm -f nodes/nodetags.h nodes/header-stamp
 	$(MAKE) -C catalog clean
diff --git a/src/include/utils/.gitignore b/src/include/utils/.gitignore
index 30f921429c6f..ff6f61cd7ee7 100644
--- a/src/include/utils/.gitignore
+++ b/src/include/utils/.gitignore
@@ -4,4 +4,6 @@
 /probes.h
 /errcodes.h
 /header-stamp
+/pgstat_wait_event.c
+/wait_event_funcs_data.c
 /wait_event_types.h
diff --git a/src/backend/Makefile b/src/backend/Makefile
index baa9b05d0211..05642dc02e39 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -136,9 +136,6 @@ parser/gram.h: parser/gram.y
 storage/lmgr/lwlocknames.h: storage/lmgr/generate-lwlocknames.pl ../include/storage/lwlocklist.h utils/activity/wait_event_names.txt
 	$(MAKE) -C storage/lmgr lwlocknames.h
 
-utils/activity/wait_event_types.h: utils/activity/generate-wait_event_types.pl utils/activity/wait_event_names.txt
-	$(MAKE) -C utils/activity wait_event_types.h pgstat_wait_event.c wait_event_funcs_data.c
-
 # run this unconditionally to avoid needing to know its dependencies here:
 submake-catalog-headers:
 	$(MAKE) -C ../include/catalog generated-headers
@@ -163,18 +160,13 @@ submake-utils-headers:
 
 .PHONY: generated-headers
 
-generated-headers: $(top_builddir)/src/include/storage/lwlocknames.h $(top_builddir)/src/include/utils/wait_event_types.h submake-catalog-headers submake-nodes-headers submake-utils-headers parser/gram.h
+generated-headers: $(top_builddir)/src/include/storage/lwlocknames.h submake-catalog-headers submake-nodes-headers submake-utils-headers parser/gram.h
 
 $(top_builddir)/src/include/storage/lwlocknames.h: storage/lmgr/lwlocknames.h
 	prereqdir=`cd '$(dir $<)' >/dev/null && pwd` && \
 	  cd '$(dir $@)' && rm -f $(notdir $@) && \
 	  $(LN_S) "$$prereqdir/$(notdir $<)" .
 
-$(top_builddir)/src/include/utils/wait_event_types.h: utils/activity/wait_event_types.h
-	prereqdir=`cd '$(dir $<)' >/dev/null && pwd` && \
-	  cd '$(dir $@)' && rm -f $(notdir $@) && \
-	  $(LN_S) "$$prereqdir/$(notdir $<)" .
-
 utils/probes.o: utils/probes.d $(SUBDIROBJS)
 	$(DTRACE) $(DTRACEFLAGS) -C -G -s $(call expand_subsys,$^) -o $@
 
diff --git a/src/backend/utils/.gitignore b/src/backend/utils/.gitignore
index 303c01d05151..fa9cfb39693d 100644
--- a/src/backend/utils/.gitignore
+++ b/src/backend/utils/.gitignore
@@ -5,3 +5,6 @@
 /guc_tables.inc.c
 /probes.h
 /errcodes.h
+/pgstat_wait_event.c
+/wait_event_funcs_data.c
+/wait_event_types.h
diff --git a/src/backend/utils/Makefile b/src/backend/utils/Makefile
index 6df31504f328..81b4a956bda3 100644
--- a/src/backend/utils/Makefile
+++ b/src/backend/utils/Makefile
@@ -43,7 +43,7 @@ generated-header-symlinks: $(top_builddir)/src/include/utils/header-stamp submak
 submake-adt-headers:
 	$(MAKE) -C adt jsonpath_gram.h
 
-$(SUBDIRS:%=%-recursive): fmgr-stamp errcodes.h guc_tables.inc.c
+$(SUBDIRS:%=%-recursive): fmgr-stamp errcodes.h guc_tables.inc.c pgstat_wait_event.c wait_event_funcs_data.c wait_event_types.h
 
 # fmgr-stamp records the last time we ran Gen_fmgrtab.pl.  We don't rely on
 # the timestamps of the individual output files, because the Perl script
@@ -58,6 +58,12 @@ errcodes.h: $(top_srcdir)/src/backend/utils/errcodes.txt generate-errcodes.pl
 guc_tables.inc.c: $(top_srcdir)/src/backend/utils/misc/guc_parameters.dat $(top_srcdir)/src/backend/utils/misc/gen_guc_tables.pl
 	$(PERL) $(top_srcdir)/src/backend/utils/misc/gen_guc_tables.pl $< $@
 
+pgstat_wait_event.c: wait_event_types.h
+wait_event_funcs_data.c: wait_event_types.h
+
+wait_event_types.h: $(top_srcdir)/src/backend/utils/activity/wait_event_names.txt $(top_srcdir)/src/backend/utils/activity/generate-wait_event_types.pl
+	$(PERL) $(top_srcdir)/src/backend/utils/activity/generate-wait_event_types.pl --code $<
+
 ifeq ($(enable_dtrace), yes)
 probes.h: postprocess_dtrace.sed probes.h.tmp
 	sed -f $^ >$@
@@ -73,8 +79,8 @@ endif
 # These generated headers must be symlinked into src/include/.
 # We use header-stamp to record that we've done this because the symlinks
 # themselves may appear older than fmgr-stamp.
-$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h probes.h guc_tables.inc.c
-	cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h probes.h guc_tables.inc.c; do \
+$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h probes.h guc_tables.inc.c pgstat_wait_event.c wait_event_funcs_data.c wait_event_types.h
+	cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h probes.h guc_tables.inc.c pgstat_wait_event.c wait_event_funcs_data.c wait_event_types.h; do \
 	  rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \
 	done
 	touch $@
@@ -93,3 +99,4 @@ uninstall-data:
 clean:
 	rm -f probes.h probes.h.tmp
 	rm -f fmgroids.h fmgrprotos.h fmgrtab.c fmgr-stamp errcodes.h guc_tables.inc.c
+	rm -f wait_event_types.h pgstat_wait_event.c wait_event_funcs_data.c
diff --git a/src/backend/utils/activity/.gitignore b/src/backend/utils/activity/.gitignore
deleted file mode 100644
index bd0c0c777298..000000000000
--- a/src/backend/utils/activity/.gitignore
+++ /dev/null
@@ -1,3 +0,0 @@
-/pgstat_wait_event.c
-/wait_event_types.h
-/wait_event_funcs_data.c
diff --git a/src/backend/utils/activity/Makefile b/src/backend/utils/activity/Makefile
index 0eb29ee78aa0..c37bfb350bbc 100644
--- a/src/backend/utils/activity/Makefile
+++ b/src/backend/utils/activity/Makefile
@@ -36,17 +36,8 @@ OBJS = \
 	wait_event.o \
 	wait_event_funcs.o
 
+# Force these dependencies to be known even without dependency info built:
+wait_event.o: wait_event.c $(top_builddir)/src/backend/utils/pgstat_wait_event.c
+wait_event_funcs.o: wait_event_funcs.c $(top_builddir)/src/backend/utils/wait_event_funcs_data.c
+
 include $(top_srcdir)/src/backend/common.mk
-
-wait_event_funcs.o: wait_event_funcs_data.c
-wait_event_funcs_data.c: wait_event_types.h
-
-wait_event.o: pgstat_wait_event.c
-pgstat_wait_event.c: wait_event_types.h
-	touch $@
-
-wait_event_types.h: $(top_srcdir)/src/backend/utils/activity/wait_event_names.txt generate-wait_event_types.pl
-	$(PERL) $(srcdir)/generate-wait_event_types.pl --code $<
-
-clean:
-	rm -f wait_event_types.h pgstat_wait_event.c wait_event_funcs_data.c
diff --git a/src/backend/utils/activity/meson.build b/src/backend/utils/activity/meson.build
index 9f48d5970e17..53bd5a246cab 100644
--- a/src/backend/utils/activity/meson.build
+++ b/src/backend/utils/activity/meson.build
@@ -30,7 +30,6 @@ waitevent_sources = files(
 wait_event = static_library('wait_event_names',
   waitevent_sources,
   dependencies: [backend_code],
-  include_directories: include_directories('../../../include/utils'),
   kwargs: internal_lib_args,
 )
 
diff --git a/src/backend/utils/activity/wait_event.c b/src/backend/utils/activity/wait_event.c
index e4f2c440257d..aca2c8fc742a 100644
--- a/src/backend/utils/activity/wait_event.c
+++ b/src/backend/utils/activity/wait_event.c
@@ -503,4 +503,4 @@ pgstat_get_wait_event(uint32 wait_event_info)
 	return event_name;
 }
 
-#include "pgstat_wait_event.c"
+#include "utils/pgstat_wait_event.c"
diff --git a/src/backend/utils/activity/wait_event_funcs.c b/src/backend/utils/activity/wait_event_funcs.c
index b62ee83ef73c..fa10a80b0887 100644
--- a/src/backend/utils/activity/wait_event_funcs.c
+++ b/src/backend/utils/activity/wait_event_funcs.c
@@ -31,7 +31,7 @@ static const struct
 
 			waitEventData[] =
 {
-#include "wait_event_funcs_data.c"
+#include "utils/wait_event_funcs_data.c"
 	/* end of list */
 	{NULL, NULL, NULL}
 };
-- 
2.51.0

---

From: Michael Paquier <[email-masked]>
Date: Fri, 30 Jan 2026 14:06:08 +0900

> able to check it there.  My manual tests across all three build

Scratch that a bit..  Some grepping is pointing out that
generated_sources_ac would become incorrect in
src/include/utils/meson.build.

Three paths in wait_event_names.txt were also inconsistent.  It is
worth noting that the sgml path is entirely wrong, this is generated
in doc/src/sgml/.  

Comments and thoughts are welcome.
--
Michael
From ac7b085172c054914bd3557bd1330681fadc68ac Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email-masked]>
Date: Fri, 30 Jan 2026 13:51:15 +0900
Subject: [PATCH v2] Fix incorrect generation of wait-event files

blah, blah..

 src/include/utils/meson.build                   |  4 +---
 src/backend/utils/activity/wait_event_names.txt |  6 +++---
 12 files changed, 27 insertions(+), 37 deletions(-)

 clean:
 	rm -f utils/fmgroids.h utils/fmgrprotos.h utils/guc_tables.inc.c utils/errcodes.h utils/header-stamp
+	rm -f utils/pgstat_wait_event.c utils/wait_event_funcs_data.c
 	rm -f storage/lwlocknames.h utils/probes.h utils/wait_event_types.h
 	rm -f nodes/nodetags.h nodes/header-stamp
 	$(MAKE) -C catalog clean
diff --git a/src/include/utils/.gitignore b/src/include/utils/.gitignore
index 30f921429c6f..ff6f61cd7ee7 100644
--- a/src/include/utils/.gitignore
+++ b/src/include/utils/.gitignore
@@ -4,4 +4,6 @@
 /probes.h
 /errcodes.h
 /header-stamp
+/pgstat_wait_event.c
+/wait_event_funcs_data.c
 /wait_event_types.h
diff --git a/src/include/utils/meson.build b/src/include/utils/meson.build
index 318a6aec0d06..fd3a2352df5d 100644
--- a/src/include/utils/meson.build
+++ b/src/include/utils/meson.build
@@ -79,8 +79,6 @@ generated_backend_headers += fmgrtab_target[1]
 
 # autoconf generates the file there, ensure we get a conflict
 generated_sources_ac += {
-  'src/backend/utils': fmgrtab_output + ['errcodes.h', 'probes.h', 'fmgr-stamp'],
+  'src/backend/utils': fmgrtab_output + ['errcodes.h', 'wait_event_types.h', 'probes.h', 'fmgr-stamp'],
   'src/include/utils': ['header-stamp'],
 }
-
-generated_sources_ac += {'src/backend/utils/activity': ['wait_event_types.h']}
diff --git a/src/backend/Makefile b/src/backend/Makefile
index baa9b05d0211..05642dc02e39 100644
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -136,9 +136,6 @@ parser/gram.h: parser/gram.y
 storage/lmgr/lwlocknames.h: storage/lmgr/generate-lwlocknames.pl ../include/storage/lwlocklist.h utils/activity/wait_event_names.txt
 	$(MAKE) -C storage/lmgr lwlocknames.h

 

 

 

 
 
 			waitEventData[] =
 {
-#include "wait_event_funcs_data.c"
+#include "utils/wait_event_funcs_data.c"
 	/* end of list */
 	{NULL, NULL, NULL}
 };
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index 5537a2d25301..efde48e76b72 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -14,13 +14,13 @@
 #
 # The files generated from this one are:
 #
-#   src/backend/utils/activity/wait_event_types.h
+#   wait_event_types.h
 #      typedef enum definitions for wait events.
 #
-#   src/backend/utils/activity/pgstat_wait_event.c
+#   pgstat_wait_event.c
 #      C functions to get the wait event name based on the enum.
 #
-#   src/backend/utils/activity/wait_event_types.sgml
+#   wait_event_types.sgml
 #      SGML tables of wait events for inclusion in the documentation.
 #
 # When adding a new wait event, make sure it is placed in the appropriate
-- 
2.51.0

---

From: Joe Hatcher <[email-masked]>
Date: Thu, 12 Mar 2026 12:05:21 +0000

Attesting to the demand for Postgres support on AIX, associated with the use of SAS, I am aware of ~200 Customers running Postgres on AIX on some 600 unique deployments.

SAS is engaged with IBM regarding Postgres on AX and is a strong advocate to have support for this operating system restored.

-------------------------------------------------------------------
Joe Hatcher
SAS Cloud and Platform - Compute Services ▪ Product Manager
Tel: 919-531-0692 ▪ Mobile: 919-624-6149
www.sas.com<http://www.sas.com/>

SAS® … THE POWER TO KNOW®

From: Aditya Kamath <[email-masked]>
Sent: Wednesday, January 28, 2026 10:20 AM
To: Srirama Kucherlapati <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: AIX support

EXTERNAL
Hi Andres,

The reason being the compiler is designed to pick what comes first in -I flag. One proof of that is here. https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html<https://protect.checkpoint.com/v2/r01/___https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MjNhNDQ4Mzg5OGFmODM2YzU1NTdkZTI1MjZhMjdkNGU6NzozMDc2OmJlMGExMGVjNjIzMDEwZTI2ODFkN2UyZDAwN2UzN2I5Y2Y4ODVjNGUyZmY2YzU2YWE5MjAyZjA3NWEwNDI1YTE6aDpUOk4>

The third we are experimenting is to have implicit_include_directories: false as per document here https://mesonbuild.com/Include-directories.html<https://protect.checkpoint.com/v2/r01/___https://mesonbuild.com/Include-directories.html___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MjNhNDQ4Mzg5OGFmODM2YzU1NTdkZTI1MjZhMjdkNGU6Nzo2MmJiOmNlN2Q4ODU3NGMwNDVmYWE5N2U3YmNhYjZiNWNmN2Y2NTY5MDJiOGYxMWUxNDNhYjIyMDdmYTFiMDljYTI2YzU6aDpUOk4>, but that might difficult since recursive include directories exists in Postgres.

Have a nice day ahead.

Thanks and regards,

Aditya.

From: Aditya Kamath <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 28 January 2026 at 3:55 PM
To: Srirama Kucherlapati <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [EXTERNAL] Re: AIX support
Hi Andrew,

We are currently experimenting with implicit_include_directories from the document below to see if we can remove the same
https://mesonbuild.com/Include-directories.html<https://protect.checkpoint.com/v2/r01/___https://mesonbuild.com/Include-directories.html___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MjNhNDQ4Mzg5OGFmODM2YzU1NTdkZTI1MjZhMjdkNGU6Nzo0Zjc5OmEwMzc4MDc4NjlhMzk2NTc5NDEwYjM0NjUyZjgwOTZjODU4MDVmYTBlYzU5MjM0OWE5ODgzMjE5ODJjNGNmZTI6aDpUOk4>.

Reason for -D_H_FLOAT

Thanks and regards,
Aditya.

From: Srirama Kucherlapati <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 28 January 2026 at 9:34 AM
To: Aditya Kamath <[email-masked]<mailto:[email-masked]>>
Subject: FW: [EXTERNAL] Re: AIX support
FYI

Warm regards,

Sriram.

VIOS/SSP Development,

ISDL, IBM India Pvt Ltd.

From: Andres Freund <[email-masked]<mailto:[email-masked]>>
Date: Monday, 26 January 2026 at 21:11
To: Srirama Kucherlapati <[email-masked]<mailto:[email-masked]>>
Cc: Peter Eisentraut <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Heikki Linnakangas <[email-masked]<mailto:[email-masked]>>, Tristan Partin <[email-masked]<mailto:[email-masked]>>, AIX PG user <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: AIX support
Hi,

> +  # https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D99557&d=DwIBAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=vAjXYU48syuVpPwT4QhmwXMV4E--HIOXIW0gSQS4cHk&m=spxpHlbU-oUOjZWtuXCtkVhprvgA3G5mhMCfcMRz7RhvcqbJQbX0erzJ-MgCiBKp&s=cdf4qUM5zjhQjv8rAUj5eMnRTtNyjaOEuuJFiHMu0uY&e=<https://protect.checkpoint.com/v2/r01/___https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99557___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MjNhNDQ4Mzg5OGFmODM2YzU1NTdkZTI1MjZhMjdkNGU6NzpjY2E0OjFkMmQxNDQ5MmVkNjk0YTk5ZDFiYzg2MTE1ZTJiMTgzODExYWVhMjA0ODFkNjEzZWI5YWMyMWYwYmIwNWZmMGE6aDpUOk4>
> +  #

Greetings,

Andres Freund