Subject: RE: AIX support

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 7 Feb 2025 16:50:30 +0000

Hi Team,
A few updates regarding the meson build.

We have successfully resolved issues with the meson build on AIX, allowing the meson configure and build to succeed.
A problem was addressed in the meson script wrt AIX (to build a nested shared libraries), specifically in the symbolextractor.py file. The fix has been implemented and will be submitted to the meson community.

https://github.com/mesonbuild/meson/blob/07f595fa98087352940121c87ba9aca0ebc95996/mesonbuild/scripts/symbolextractor.py#L4

Currently, we are verifying the test results.

Warm regards,
Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 7 Mar 2025 14:11:43 +0000

Hi Team,
Our team has identified couple of issues with the meson build on AIX, primarily focusing on the following areas:

  1.  Symbol extraction and resolution in object files during binary creation.
  2.  Dynamic runtime library path resolution in shared libraries.
We have resolved them and we plan to submit these fixes to the meson community shortly.

In addition, we are actively working on resolving other test issues. I will provide you with updates once these problems have been resolved.

92/301 postgresql:regress / regress/regress
    # 4 of 223 tests failed.

Warm regards,
Sriram.

---

From: Robert Haas <[email-masked]>
Date: Fri, 7 Mar 2025 11:20:14 -0500

On Fri, Mar 7, 2025 at 9:11 AM Srirama Kucherlapati
<[email-masked]> wrote:
> Symbol extraction and resolution in object files during binary creation.
> Dynamic runtime library path resolution in shared libraries.
>

Nice!

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

---

From: Srirama Kucherlapati <[email-masked]>
Date: Mon, 17 Mar 2025 16:58:04 +0000

Hi Team,
Here are the updates on the meson on AIX.  Our team had pushed the fixes meson github here …

https://github.com/mesonbuild/meson/pull/14335

#14335 Enhance AIX shared library build to use an export List.<https://github.com/mesonbuild/meson/pull/14335>

---

From: wenhui qiu <[email-masked]>
Date: Thu, 3 Apr 2025 16:25:15 +0800

HI Srirama
     It's getting close to  code freeze. Any updates from your end?

Thanks

On Tue, Mar 18, 2025 at 12:58 AM Srirama Kucherlapati <[email-masked]>
wrote:

> #14335 Enhance AIX shared library build to use an export List.
> <https://github.com/mesonbuild/meson/pull/14335>
>
>
>
>
>
>
>
>

---

From: Srirama Kucherlapati <[email-masked]>
Date: Thu, 3 Apr 2025 13:45:01 +0000

Hi Wenhui Qiu,

May I know the freeze dates.

We are nearly ready to deliver the patch. Currently, we have compiled the
source using Meson and are investigating one test case issue. Once we pinpoint
the cause, we will send you the patch. Notably, this test case behaves
differently on AIX, opting for a Bitmap Index Scan instead of an Index Scan.
Not sure if this is really specific to AIX?

                >> meson test

396 Ok:                 81
397 Expected Fail:      0
398 Fail:               1  (regex)
399 Unexpected Pass:    0
400 Skipped:            219
401 Timeout:            0

  7  explain (costs off) select * from pg_proc where proname ~ '^abc';
  8 -                              QUERY PLAN
  9 -----------------------------------------------------------------------
10 - Index Scan using pg_proc_proname_args_nsp_index on pg_proc
11 -   Index Cond: ((proname >= 'abc'::text) AND (proname < 'abd'::text))
12 +                                 QUERY PLAN
13 +----------------------------------------------------------------------------
14 + Bitmap Heap Scan on pg_proc
15     Filter: (proname ~ '^abc'::text)
16 -(3 rows)
17 +   ->  Bitmap Index Scan on pg_proc_proname_args_nsp_index
18 +         Index Cond: ((proname >= 'abc'::text) AND (proname < 'abd'::text))
19 +(4 rows)

As of now below are the changes wrt to meson.

        modified:   meson.build
        modified:   src/backend/meson.build
        modified:   src/bin/initdb/initdb.c
        modified:   src/include/c.h
        modified:   src/include/port/aix.h
        modified:   src/include/utils/float.h
        modified:   src/interfaces/ecpg/compatlib/meson.build
        modified:   src/interfaces/ecpg/ecpglib/meson.build
        modified:   src/interfaces/ecpg/pgtypeslib/meson.build
        modified:   src/interfaces/libpq/meson.build
        modified:   src/test/regress/expected/txid.out
        modified:   src/test/regress/expected/xid.out
        modified:   src/test/regress/sql/sanity_check.sql

Warm regards,
Sriram.

---

From: Heikki Linnakangas <[email-masked]>
Date: Thu, 3 Apr 2025 16:49:59 +0300

> May I know the freeze dates.

April 8th is the feature freeze. Any new features must be *committed* by 
then. We are already very close to that, and given that there's no 
concrete patch for committer to review yet, I think it's safe to say 
that you missed it already.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Andres Freund <[email-masked]>
Date: Thu, 3 Apr 2025 09:54:00 -0400

Hi,

> Not sure if this is really specific to AIX?

FWIW, the skipped tests indicate that you are building without tap tests or
such - that means most of the testsuite is not run. That certainly is not good
enough.

Greetings,

Andres Freund

---

From: Srirama Kucherlapati <[email-masked]>
Date: Fri, 4 Apr 2025 19:31:58 +0000

Hi Heikki and team,

Thank you for considering our request. As discussed, we have revised the patch
to incorporate all the review comments provided.
Please find the attached patch, which focuses solely on the gmake changes.
As discussed the meson specific changes would be provided as different patch.

We have taken into account and resolved the earlier comments within this patch.
https://www.postgresql.org/message-id/e0dc2bff-300b-4edd-912b-b6c52274bdc5%40iki.fi

- Build using latest master. (used commit 898c131b58a0b)
   - We have merged our changes to this latest level.
- configure.ac
   - Updated the changes aligning to configure file.
- configure
   - Updated the comments wrt to the alignment details. Updated with
     the gcc specific fix which talks about the alignment.
  - updated the int64_t specific changes.
- doc/src/sgml/dfunc.sgml
  - This is removed as it is not relevant.
- src/backend/port/aix/mkldexport.sh
  - When building shared libraries from various archives on AIX, we encounter a
     situation where symbols are not exported. To resolve this, we require an export
     file. For instance, the command is used to export symbols.
     gcc -shared libtest.so libtest.a -Wl,-bE:test.exp

     However, if we directly provide object files in the command line instead of an
     archive, the symbols will be exported automatically, as demonstrated by the command
     gcc -shared libtest.so test1.o test2.o test3.o.
   - We will update the description with additional details in the later point of time. (Considering the time lines)

- src/makefiles/Makefile.aix
   - The changes in this file are required
   - This change is not required “+LDFLAGS_SL += -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE”
- src/template/aix
   - WRT to the MEMSET_LOOP_LIMIT flag, this is set to “0”, which would internally use
     The system call memset() as mentioned in the below link as well

     https://www.postgresql.org/message-id/20060203135315.E08B09DC816%40postgresql.org

I Kindly request you to review the changes and provide your feedback.

With all the above changes we have built and ran the tests. As of now we see
there is only one test case that is failing, which seems to have been
introduced recently. And this might not be related to the above changes as
earlier there were no test cases failing.

64 not ok 12    + float8                   235 ms

297 # 1 of 226 tests failed.

20 +ERROR:  value out of range: overflow
21  -- test overflow/underflow handling
22  SELECT gamma(float8 '-infinity');
23  ERROR:  value out of range: overflow

Warm regards,
Sriram.

---

From: Heikki Linnakangas <[email-masked]>
Date: Fri, 4 Apr 2025 23:44:00 +0300

On 04/04/2025 22:31, Srirama Kucherlapati wrote:
 > - src/backend/port/aix/mkldexport.sh>

Oh, that's interesting. So if we do that, we don't need mkldepxort.sh 
anymore?

> https://www.postgresql.org/message- 
> id/20060203135315.E08B09DC816%40postgresql.org <https:// 
> www.postgresql.org/message-id/20060203135315.E08B09DC816%40postgresql.org>

Yes, I understand what it does. But why? Whatever benchmarking was done 
back in 2006 by is no longer relevant.

> 23  ERROR:  value out of range: overflow

Yeah, that function is new. I don't know if it's a pre-existing problem 
or something specific to AIX. Please check the archives for prior 
discussion on that; if you can reproduce it, maybe you can help to fix it?

>  12 files changed, 224 insertions(+), 20 deletions(-)

I'm glad to see this patch shrinking :-)

> diff --git a/src/include/port/aix.h b/src/include/port/aix.h
> new file mode 100644
> index 00000000000..7d08480c8c0
> --- /dev/null
> +++ b/src/include/port/aix.h
> @@ -0,0 +1,4 @@
> +/*
> + * src/include/port/aix.h
> + */
> +

Useless.

> diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
> index 2f73f9fcf57..5da9b3acda4 100644
> --- a/src/include/storage/s_lock.h
> +++ b/src/include/storage/s_lock.h
> @@ -421,17 +421,15 @@ tas(volatile slock_t *lock)
>  	__asm__ __volatile__(
>  "	lwarx   %0,0,%3,1	\n"
>  "	cmpwi   %0,0		\n"
> -"	bne     1f			\n"
> +"	bne     $+16		\n"		/* branch to li %1,1 */
>  "	addi    %0,%0,1		\n"
>  "	stwcx.  %0,0,%3		\n"
> -"	beq     2f			\n"
> -"1: \n"
> +"	beq     $+12		\n"		/* branch to lwsync */
>  "	li      %1,1		\n"
> -"	b       3f			\n"
> -"2: \n"
> +"	b       $+12		\n"		/* branch to end of asm sequence */
>  "	lwsync				\n"
>  "	li      %1,0		\n"
> -"3: \n"
> +
>  :	"=&b"(_t), "=r"(_res), "+m"(*lock)
>  :	"r"(lock)
>  :	"memory", "cc");

Why is this change needed?

Yes, I know we've been over this many times already. I still don't 
understand why it's needed. The onus is on you to explain it adequately, 
in comments in the patch, so that I and others understand it. Or even 
better, remove it if it's not necessary.

> diff --git a/src/makefiles/Makefile.aix b/src/makefiles/Makefile.aix
> new file mode 100644
> index 00000000000..d33918f91b9
> --- /dev/null
> +++ b/src/makefiles/Makefile.aix
> @@ -0,0 +1,39 @@
> +# MAKE_EXPORTS is required for svr4 loaders that want a file of
> +# symbol names to tell them what to export/import.
> +MAKE_EXPORTS= true

Oh this is interesting. I think MAKE_EXPORTS is actually a leftover that 
I failed to remove when I removed the AIX support; it's not used on any 
currently-supported platform.

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

Is this still sensible on modern AIX systems? What happens if you leave 
it out?

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

Same here. Still relevant? What happens if you leave it out?

> +# gcc needs to know it's building a shared lib, otherwise it'll not emit
> +# correct code / link to the right support libraries
> +ifeq ($(GCC), yes)
> +LDFLAGS_SL += -shared
> +endif

On other platforms, we have this in LINK.shared, see src/Makefile.shlib. 
Should we do the same on AIX; if not, why not?

> +# env var name to use in place of LD_LIBRARY_PATH
> +ld_library_path_var = LIBPATH

Does AIX have LD_LIBRARY_PATH? This suggests that it does:

https://www.ibm.com/support/pages/aix-libpath-recommendations

What's the difference between LIBPATH and LD_LIBRARY_PATH? Why prefer 
LIBPATH?

Separately from the remaining issues with this patch, I still feel 
pretty reluctant with accepting this, because if I commit this patch, 
I'm on the hook to keep it working. I do regularly commit stuff that I'm 
not personally that interested in, but a new port is different:

If something breaks on AIX, I have no means (or interest!) in debugging 
it. That means that I need to be pretty confident that there are others 
who are interested and invested in keeping working, take ownership, will 
help to debug problems in a timely fashion, and can submit high-quality 
fixes. I am not seeing that.

I also notice that all the AIX systems we have in the buildfarm are still:

- maintained by Noah, who - correct me if I'm wrong - is not 
particularly interested in AIX or keen on maintaining them
- are on AIX 7.1.5, which I believe is already end-of-line
- running on power7 hardware which is 15 years old.

That's not very reassuring.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Srirama Kucherlapati <[email-masked]>
Date: Sat, 5 Apr 2025 18:29:50 +0000

Hi Heikki,
Please find the attached patch addressing the provided comments. Our responses are outlined below.

> Oh, that's interesting. So if we do that, we don't need mkldepxort.sh

Here the better approach still would be to use the script to extract the
symbols build the corresponding shared libraries.  As we see there are
lot of extensions that are getting built using the symbols exported from
"postges" binary, we need to definitely  use the script to extract the symbols
and import them while building the library extensions.

> back in 2006 by is no longer relevant.

We ran the program , mentioned in the below link and collected the

benchmark stats on our node (POWER_10).

    https://postgrespro.com/list/thread-id/1673194

The native AIX memset() seems to performs better. The benchmark seems to be still

relevant, so I think we should continue to use the existing optimization for

AIX. Below are the stats (64bit Object mode).

>> ./memset-aix

        sizeof(int)  = 4

        sizeof(long) = 8

        Loop by int (size=8) : 0.238024

        memset by int (size=8) : 0.280301

        Loop by long (size=8) : 0.202650

        Loop by int (size=16) : 0.389846

        memset by int (size=16) : 0.280979

        Loop by long (size=16) : 0.246879

        Loop by int (size=32) : 0.773478

        memset by int (size=32) : 0.331691

        Loop by long (size=32) : 0.422261

        Loop by int (size=64) : 1.945150

        memset by int (size=64) : 0.319117

        Loop by long (size=64) : 0.769770

        Loop by int (size=128) : 4.517186

        memset by int (size=128) : 0.398292

        Loop by long (size=128) : 1.982307

        Loop by int (size=256) : 12.486661

        memset by int (size=256) : 0.463115

        Loop by long (size=256) : 4.526272

        Loop by int (size=512) : 24.433075

        memset by int (size=512) : 0.681426

        Loop by long (size=512) : 12.564701

        Loop by int (size=1024) : 48.060486

        memset by int (size=1024) : 0.904048

        Loop by long (size=1024) : 24.149871

        Loop by int (size=2048) : 96.288018

        memset by int (size=2048) : 1.509465

        Loop by long (size=2048) : 48.216079

        Loop by int (size=4096) : 191.847177

        memset by int (size=4096) : 1.435403

        Loop by long (size=4096) : 96.433072

> I'm glad to see this patch shrinking :-)

Thanks for your suggestions, yes it further shrinked.

> Useless.

I too initially felt this was not needed, This file is still required as the below file is

getting auto generated. I attempted to remove it; the below error is hit.

so this is still required.

     64 ../../src/include/c.h:59:10: fatal error: pg_config_os.h: No such file or directory

     65    59 | #include "pg_config_os.h"               /* config from include/port/PORTNAME.h */

     66       |          ^~~~~~~~~~~~~~~~

> better, remove it if it's not necessary.

If you recall, we previously considered replacing this assembly code with
__sync_lock_test_and_set(). However, as you mentioned earlier, this should be
handled in a separate patch. For now, I'll make a note and submit a separate
patch for this later, as originally planned. Below is the reference to older
discussion.
https://www.postgresql.org/message-id/7751f9c5-e2e6-4252-a9fa-14b3e78ddec9%40iki.fi

>currently-supported platform.

Removed it and its working fine.

> Is this still sensible on modern AIX systems? What happens if you leave

This is required as it is looking for the possible non-default directories for the linker

at the runtime. This is used along with rpath. As suggested, I tested this by removing

the libpath, but at run time the linker is not able to find the dependent libraries path

as a result, the binaries are not getting loaded. After doing some research, AIX uses a stricter,

more explicit approach. The runtime linker expects to tell it exactly where to look using -blibpath.

> Same here. Still relevant? What happens if you leave it out?

Removed it and it is working fine.

>Should we do the same on AIX; if not, why not?

I tried your suggestion to move the gcc "LDFLAGS_SL += -shared" flag to Makefile.shlib,

"LINK.shared       = $(COMPILER) -shared", but there are some extensions dependent

on this in "contrib" which are not building with “-shared” flag, as a result a testcase

is failing to load this library "contrib/spi/autoinc.so" . Below is the error.

not ok 78    + triggers                                 2443 ms

31 +ERROR:  incompatible library "/home/pgdev/pgdb/postgres/src/test/regress/autoinc.so": missing magic block

32 +HINT:  Extension libraries are required to use the PG_MODULE_MAGIC macro.

I noticed that the “-shared” flag was missing while building the contrib/spi/autoinc.so library.

I tried to add the “include $(top_builddir)/src/Makefile.shlib” in the

contrib/spi/Makefile, but still the “-shared” flag is not getting included while building

the library.
So we will continue to use the earlier change.

LIBPATH?

AIX uses only LIBPATH and  LD_LIBRARY_PATH is specific to Linux.

> fixes. I am not seeing that.

I completely understand your concerns about committing to a new port and
ensuring its long-term maintenance.
Our team would like to extend the support to maintain PostgreSQL on AIX.
We would like to assist by timely debugging and resolving any issues on AIX.
We’re also keen to actively contribute to this effort.

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 7 Apr 2025 13:04:39 +0300

On 05/04/2025 21:29, Srirama Kucherlapati wrote:
> https://postgrespro.com/list/thread-id/1673194 <https://postgrespro.com/ 
> list/thread-id/1673194>
> 
> The native AIX memset() seems to performs better. The benchmark seems to 
> be still relevant, so I think we should continue to use the existing optimization for
> AIX.

At least it needs to be updated to match what MemSet() looks like 
nowadays. The changes may be just cosmetic, but better check. Should 
also check the effect on MemSetAligned(). That might matter more for 
performance in practice.

A third thing to check is the performance of MemSet() when the pointer 
is, in fact, aligned.

The other question is what do the results look like on other platforms? 
How much difference does the libc implementation make, vs. the compiler 
and CPU architecture? If the difference is related to compiler or CPU 
architecture, then this doesn't belong in the AIX template, but 
somewhere else.

> Below are the stats (64bit Object mode).
> 
>>> ./memset-aix
> 
>          sizeof(int)  = 4
>          sizeof(long) = 8

MemSet() uses 'long', so the int tests are not relevant. I have omitted 
them below.

>          Loop by long (size=32) : 0.422261

Ok, MemSet() is faster with very small sizes, the crossover is somewhere 
between 16 and 32 bytes.

I'm actually surprised the compiler doesn't replace the memset() call 
with a few store instructions with these sizes.

>          Loop by long (size=1024) : 24.149871

So with larger sizes, memset() wins hands down.

I'm surprised how big the difference is, because I actually expected the 
compiler to detect the memory-zeroing loop and replace it with some 
fancy vector instructions (does powerpc have any?). Or a call to 
memset(); I've seen compilers convert loops to memset() and vice versa.

My gut feeling is actually that we should remove the MemSet() macro 
altogether and just use memset() everywhere. The compilers are much 
better at optimizing it in year 2025 than they were back in 2002. I'd 
love to see some rigorous benchmarks across different platforms and 
compilers to demonstrate that, and then just get rid of MemSet().

MemSetAligned() might still be worth keeping. Sometimes we know that a 
piece of memory is aligned, but the compiler does not. But maybe even 
that should just assert and hint the compiler that the input is aligned, 
and then call memset().

If you'd like to help the community in general, if you could do some 
more rigorous benchmarking along those lines, not just for AIX, and 
start a new thread to discuss that, that'd be much appreciated. That 
would be the best way to resolve this.

For the more narrow question of what should the AIX template do, that 
comes down to whether there's some *AIX-specific* performance 
difference. The generated powerpc assembly code is presumably the same 
on AIX and other operating systems, so it comes down to whether there's 
some big difference in AIX's memset() implementation vs. glibc's.

> If you recall, we previously considered replacing this assembly code 
> with __sync_lock_test_and_set(). However, as you mentioned earlier, 
> this should be handled in a separate patch. For now, I'll make a 
> note and submit a separate patch for this later, as originally
> planned. Below is the reference to older discussion.

Yes, I do recall. Please read again my comment above: this all needs to 
be explained in comments in the code.

To be precise, I have these questions:

- Does GCC on AIX (still) use the IBM assembler?
- Does the IBM assembler still not understand the label syntax?
- Is there some other label syntax that would work on the IBM assembler?
- Is it possible to use the GNU assembler instead?

> This is required as it is looking for the possible non-default 
> directories for the linker at the runtime. This is used along with
> rpath. As suggested, I tested this by removing the libpath, but at
> run time the linker is not able to find the dependent libraries path 
> as a result, the binaries are not getting loaded. After doing some 
> research, AIX uses a stricter, more*explicit* approach. The runtime
> linker expects to tell it exactly where to look using -blibpath.

Ok, some comments would be in order to explain that, maybe with links to 
the relevant AIX documentation.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

---

From: Srirama Kucherlapati <[email-masked]>
Date: Sat, 12 Apr 2025 16:41:55 +0000

Here are some stats wrt to loop and native memset after enabling optimization with the same test tool(tested for long and long align using MemSetAligned). Corresponding glibc is linked on PPcle and AIX libc is linked on AIX.

                                        AIX loop-1  PPCle - loop1   AIX loop-2  PPCle - loop2
    Loop by long (size=8)           :   0           0               0.000001    0
    Loop Align by long (size=8)     :   0           0               0           0
    memset by long (size=8)         :   0.00999     0.010229        0.00994     0.010211
    Loop by long (size=16)          :   0           0               0           0
    Loop Align by long (size=16)    :   0           0               0           0
    memset by long (size=16)        :   0.010082    0.010036        0.010094    0.01003
    Loop by long (size=32)          :   0.32903     0.227726        0.329027    0.227707
    Loop Align by long (size=32)    :   0.329486    0.227705        0.328932    0.227712
    memset by long (size=32)        :   0.021061    0.01064         0.021115    0.01064
    Loop by long (size=64)          :   0.334761    0.227714        0.34326     0.227688
    Loop Align by long (size=64)    :   0.329005    0.236937        0.329084    0.236906
    memset by long (size=64)        :   0.059559    0.025612        0.053004    0.029589
    Loop by long (size=128)         :   0.420381    0.329634        0.420332    0.329524
    Loop Align by long (size=128)   :   0.420376    0.337169        0.42022     0.337162
    memset by long (size=128)       :   0.420153    0.098774        0.420312    0.101888
    Loop by long (size=256)         :   0.472187    0.428049        0.472774    0.429217
    Loop Align by long (size=256)   :   0.472586    0.438316        0.472447    0.438325
    memset by long (size=256)       :   0.473731    0.428013        0.473864    0.42759
    Loop by long (size=512)         :   0.676089    0.435649        0.632774    0.43574
    Loop Align by long (size=512)   :   0.66702     0.428013        0.630751    0.427319
    memset by long (size=512)       :   0.666619    0.427989        0.691485    0.427263
    Loop by long (size=1024)        :   1.00773     0.45079         0.925212    0.452131
    Loop Align by long (size=1024)  :   0.92114     0.45084         0.920574    0.452994
    memset by long (size=1024)      :   0.935062    0.450821        0.917       0.452396
    Loop by long (size=2048)        :   1.52585     0.702127        1.265107    0.701822
    Loop Align by long (size=2048)  :   1.57524     0.702158        1.439109    0.702651
    memset by long (size=2048)      :   1.614771    0.702247        1.384672    0.701857
    Loop by long (size=4096)        :   1.418133    1.37568         1.325803    1.376005
    Loop Align by long (size=4096)  :   1.421619    1.375741        1.325743    1.376071
    memset by long (size=4096)      :   1.423404    1.375716        1.325666    1.376091

After enabling optimization levels, both are performing similar.
As both are performing similar we have removed the MEMSET_LOOP in the AIX template and tried the below benchmark after running pgbench.

    Run#1
    >> pgbench -c 50 -p 5678 -d postgres -T 180 -r -P 10  -L 10 -j 20
    pgbench (18devel)
    starting vacuum...end.
    progress: 10.0 s, 2603.2 tps, lat 18.692 ms stddev 61.947, 0 failed
    progress: 20.0 s, 3373.2 tps, lat 14.841 ms stddev 17.724, 0 failed
    progress: 30.0 s, 2599.6 tps, lat 19.222 ms stddev 99.307, 0 failed
    progress: 40.0 s, 3531.3 tps, lat 14.159 ms stddev 14.786, 0 failed
    progress: 50.0 s, 2561.3 tps, lat 15.180 ms stddev 33.532, 0 failed
    progress: 60.0 s, 3315.4 tps, lat 18.421 ms stddev 111.988, 0 failed
    progress: 70.0 s, 3517.4 tps, lat 14.203 ms stddev 14.931, 0 failed
    progress: 80.0 s, 2023.4 tps, lat 21.858 ms stddev 125.718, 0 failed
    progress: 90.0 s, 3472.1 tps, lat 16.049 ms stddev 55.152, 0 failed
    progress: 100.0 s, 3580.5 tps, lat 13.966 ms stddev 14.636, 0 failed
    progress: 110.0 s, 2823.4 tps, lat 14.572 ms stddev 20.433, 0 failed
    progress: 120.0 s, 3140.3 tps, lat 18.717 ms stddev 120.447, 0 failed
    progress: 130.0 s, 3488.4 tps, lat 14.329 ms stddev 15.057, 0 failed
    progress: 140.0 s, 2503.7 tps, lat 19.966 ms stddev 125.551, 0 failed
    progress: 150.0 s, 3083.3 tps, lat 16.212 ms stddev 56.652, 0 failed
    progress: 160.0 s, 3572.0 tps, lat 13.991 ms stddev 14.660, 0 failed
    progress: 170.0 s, 3642.2 tps, lat 13.722 ms stddev 14.507, 0 failed
    progress: 180.0 s, 2453.6 tps, lat 20.364 ms stddev 133.126, 0 failed
    transaction type: <builtin: TPC-B (sort of)>
    scaling factor: 50
    query mode: simple
    number of clients: 50
    number of threads: 20
    maximum number of tries: 1
    duration: 180 s
    number of transactions actually processed: 552889
    number of failed transactions: 0 (0.000%)
    number of transactions above the 10.0 ms latency limit: 227816/552889 (41.205%)
    latency average = 16.252 ms
    latency stddev = 69.656 ms
    initial connection time = 237.245 ms
    tps = 3074.421213 (without initial connection time)
    statement latencies in milliseconds and failures:
             0.002           0 \set aid random(1, 100000 * :scale)
             0.001           0 \set bid random(1, 1 * :scale)
             0.001           0 \set tid random(1, 10 * :scale)
             0.001           0 \set delta random(-5000, 5000)
             1.090           0 BEGIN;
             3.153           0 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
             1.462           0 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
             2.012           0 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
             4.060           0 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
             1.224           0 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_T
             3.246           0 END;

    Run#2
    >> pgbench -c 50 -p 5678 -d postgres -T 180 -r -P 10  -L 10 -j 20
    pgbench (18devel)
    starting vacuum...end.

    transaction type: <builtin: TPC-B (sort of)>
    scaling factor: 50
    query mode: simple
    number of clients: 50
    number of threads: 20
    maximum number of tries: 1
    duration: 180 s
    number of transactions actually processed: 577290
    number of failed transactions: 0 (0.000%)
    number of transactions above the 10.0 ms latency limit: 234815/577290 (40.675%)
    latency average = 15.558 ms
    latency stddev = 65.428 ms
    initial connection time = 314.109 ms
    tps = 3211.642930 (without initial connection time)
    statement latencies in milliseconds and failures:
             0.002           0 \set aid random(1, 100000 * :scale)
             0.001           0 \set bid random(1, 1 * :scale)
             0.001           0 \set tid random(1, 10 * :scale)
             0.001           0 \set delta random(-5000, 5000)
             1.084           0 BEGIN;
             2.761           0 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
             1.371           0 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
             2.000           0 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
             4.014           0 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
             1.229           0 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_T
             3.093           0 END;

> - Is it possible to use the GNU assembler instead?

GCC on AIX still uses the AIX native assembler only. The GNU assembler has some level of support in AIX through some of the patches. But still GCC/gnu assembler combination is not very much tested.

We removed AIX specific changes for TAS(), which would now use the __sync_lock_test_and_set() routines directly instead, and we ran pgbench on it.

    + pgbench -c 50 -p 5678 -d postgres -T 180 -r -P 10 -L 10 -j 20
    pgbench (18devel)
    starting vacuum...end.

    scaling factor: 50
    query mode: simple
    number of clients: 50
    number of threads: 20
    maximum number of tries: 1
    duration: 180 s
    number of transactions actually processed: 550838
    number of failed transactions: 0 (0.000%)
    number of transactions above the 10.0 ms latency limit: 227805/550838 (41.356%)
    latency average = 16.323 ms
    latency stddev = 68.404 ms
    initial connection time = 235.449 ms
    tps = 3061.041640 (without initial connection time)
    statement latencies in milliseconds and failures:
             0.002           0 \set aid random(1, 100000 * :scale)
             0.001           0 \set bid random(1, 1 * :scale)
             0.001           0 \set tid random(1, 10 * :scale)
             0.001           0 \set delta random(-5000, 5000)
             1.098           0 BEGIN;
             2.993           0 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
             1.501           0 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
             2.004           0 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
             4.127           0 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
             1.238           0 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
             3.356           0 END;

> 23  ERROR:  value out of range: overflow

WRT failure in lgamma(), we worked with the libm team to resolve it. It’s an issue with the errno that is being set. I’ll work on the testcase.

   >> ./gamma-test NaN

    Gamma and natural logarithm of gamma for the input values:
    Gamma(NaNS) = NaNQ errno: 34
    lgamma(NaNS) = NaNQ errno: 34

   With fixed libm

    + ./gamma-test NaN

    Gamma and natural logarithm of gamma for the input values:
    Gamma(NaNS) = NaNQ errno: 0
    lgamma(NaNS) = NaNQ errno: 0

Warm Regards,
Sriram

---

From: Srirama Kucherlapati <[email-masked]>
Date: Sat, 12 Apr 2025 17:09:41 +0000

Working on the patch. I will update you.

-Sriram.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 15 Apr 2025 16:20:41 +0000

Hi Team, Please find the attached diff with the latest changes.

The diff file changes that were done for memset and spinlock, are modified
on top of the previous patch.

New changes for review: 0001-AIX-support.tas.memset.diffs
Previous patch: 0001-AIX-support.v8.patch

>> diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
We have replaced the asm code with the gcc specific routines __sync_lock_test_and_set ()
and ran the pgbench. On AIX both have the similar performance, On PPcle we see a slight
variation in the performance. It seems the asm code is performing better on PPCle. Please
let us know, would it be better to continue to use the PPC assemble code over gcc routines.

Attached are the complete stats. (spinlock.stats.log)
Below is the summary…

                        AIX With asm    AIX With __sync   PPCle With asm  PPCle With __sync
number of transactions "226554/         "230810/          "356945/        "364346/
above the 10.0 ms       556329          567936            918647          863937
latency limit           (40.723%)"      (40.640%)"       (38.856%)"       (42.173%)"

latency average         16.160 ms       15.821 ms         9.796 ms        10.416 ms
initial connection time 230.786 ms      249.668 ms        19.606 ms       20.090 ms
tps                     3086.209412     3158.14915        5103.024267     4799.621896

> also check the effect on MemSetAligned(). That might matter more for

As per the stats in the previous mail wrt to memset, both the loop and the native
memset are performing similar after optimization “-O2”. So for now we removed the
native memset changes.
We will setup the memset performance on different platforms and will post the
details in a different thread.

>>> +libpath := $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -e's/ //g'):/usr/lib:/lib

Added additional details about the -blibpath usage. These details are available in the below link
https://download.boulder.ibm.com/ibmdl/pub/software/dw/aix/es-aix_ll.pdf

> 23  ERROR:  value out of range: overflow

This testcase is resolved from AIX libm side. Below is the result.

postgres=#
SELECT x, gamma(x),lgamma(x)
FROM (VALUES (0.5), (1), (2), (3), (4), (5),
(float8 'infinity'), (float8 'nan')) AS t(x);

      0.5 | 1.772453850905516 | 0.5723649429247001
        1 |                 1 |                  0
        2 |                 1 |                  0
        3 |                 2 | 0.6931471805599453
        4 |                 6 |  1.791759469228055
        5 |                24 | 3.1780538303479458
Infinity |          Infinity |           Infinity
      NaN |               NaN |                NaN

Kindly let us know your feedback on the diffs.
I will commit the diffs to the patch(0001-AIX-support.v8.patch) once you are fine.

Warm regards,
Sriram.

---

From: Thomas Munro <[email-masked]>
Date: Fri, 25 Apr 2025 13:31:46 +1200

On Mon, Apr 7, 2025 at 10:04 PM Heikki Linnakangas <[email-masked]> wrote:
> fancy vector instructions (does powerpc have any?).

It certainly does, and we've played with explicit AltiVec
vectorisation before with the idea that our abstraction over x86 and
ARM instructions could be extended to POWER, but that was just trying
stuff and learning while wondering if those abstractions are general
enough and how well all the instructions match up.  No one with modern
hardware and a vested interest has seriously investigated it.  That's
independent of automatic vectorisation done by the compiler or libc,
and I guess it would not really be AIX-specific since it would also
apply to Linux on POWER.  One of those patches is linked from this
small list of "ideas for a future PostgreSQL/AIX maintainer":

https://wiki.postgresql.org/wiki/AIX

---

From: Srirama Kucherlapati <[email-masked]>
Date: Wed, 3 Sep 2025 16:44:00 +0000

Hi Heikki and team,

As part of our ongoing efforts to enhance AIX platform compatibility, we’ve been running the code across all stable PostgreSQL release branches using the build farm infrastructure. All test suites, including TAP tests, are passing consistently, indicating no regressions.

https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=douc&br=REL_13_STABLE
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=douc&br=REL_14_STABLE
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=douc&br=REL_15_STABLE
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=douc&br=REL_16_STABLE << Also tested locally.

To further validated the patch, we executed the build farm scripts locally for PostgreSQL 17 and 18 on AIX. The corresponding test results are attached for reference.

We value your feedback and would appreciate your insights on the attached patch. Kindly request you to review and share your comments.

Warm regards,
Sriram.

---

From: Vamshikrishna T <[email-masked]>
Date: Thu, 11 Sep 2025 10:50:45 +0530

Hi Team,

Just checking in regarding the AIX support patch shared earlier. As
mentioned, we’ve successfully run the patch across all stable PostgreSQL
releases using the build farm, and all tests—including TAP—have passed. We
also ran the build farm scripts locally for PostgreSQL 17 and 18 on AIX,
and the test results were attached for your reference.

We’d appreciate your review and feedback on the patch. Once we receive your
input, our next steps will be:

1. Address any comments or suggestions you may have.

2. Finalize the patch based on feedback.

3. Proceed with integration into the relevant branches.

Please let us know if you need any additional details or clarification.

Thanks

 Vamshi.

---

From: Laurenz Albe <[email-masked]>
Date: Thu, 11 Sep 2025 08:12:39 +0200

On Thu, 2025-09-11 at 10:50 +0530, Vamshikrishna T wrote:
> Just checking in regarding the AIX support patch shared earlier.

Did you create a commitfest entry?
That way, your patch is less likely to fall between the cracks.

Yours,
Laurenz Albe

---

From: Vamshikrishna T <[email-masked]>
Date: Thu, 11 Sep 2025 10:48:57 +0000

Thank you Laurenz for the info, Raised the review request here.

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 15 Sep 2025 19:44:04 -0400

> 3. Proceed with integration into the relevant branches.        

I assume the only relevant branch is PG 19.

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 16 Sep 2025 15:13:30 +0000

Hi Bruce,
Please find the attached patch that is run on master branch PG19.
Kindly request you to go through and let us know your feedback.

Also attached are the builfarm results.

Warm regards,
Sriram.

---

From: Vamshikrishna T <[email-masked]>
Date: Thu, 18 Sep 2025 06:21:51 +0000

This patch marked 10/10 with all CI checks passing. Your feedback on the patch would be greatly appreciated.

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 20 Sep 2025 17:20:48 +0200

On 2025-Sep-03, Srirama Kucherlapati wrote:

> As part of our ongoing efforts to enhance AIX platform compatibility,
> we’ve been running the code across all stable PostgreSQL release
> branches using the build farm infrastructure. All test suites,
> including TAP tests, are passing consistently, indicating no
> regressions.

The buildfarm results you sent look good.  You should definitely be
testing branch master though rather than the stable ones, because it's
not clear to me, as Bruce said, that we would really backpatch AIX
support to stable branches.  (You're of course free to produce your own
packages from patched versions, in the interim).

I noticed that you add mkldexport.sh and that the makefiles use it.  I
wonder if that really is necessary with the current AIX tooling (it
looks an outdated gadget).

Also, I notice that Meson supports AIX starting from version 0.56; did
you verify whether it works to build this with that?

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

---

From: AIX PG user <[email-masked]>
Date: Mon, 22 Sep 2025 11:09:53 +0000

Hi Alvaro,
Thank you for taking your time to look into the details.

I’ve submitted the latest changes to the master branch, which are now available in the annotations section here:
    https://commitfest.postgresql.org/patch/6050/
I kindly request you to review this updated patch and share your valuable feedback.

Regarding your observation about the inclusion of mkldexport.sh and its usage in the makefiles — as previously 
discussed, this is a necessary workaround due to current limitations on AIX. To build shared libraries, we need to 
extract symbols using this script. The relevant details are as follows:
  Script Location: src/backend/port/aix/mkldexport.sh
  Purpose: Implements AIX-specific changes for shared library creation using export files.
  Background: Based on discussions with the internal linker team, this method is currently required to extract symbols and build shared libraries.
  Reference Practices: This approach is consistent with methods used in other open-source projects such as Python and OpenBLAS:
  Python
    https://github.com/python/cpython/blob/main/Modules/ld_so_aix.in
  OpenBLAS
    https://github.com/OpenMathLib/OpenBLAS/commit/892f8ff3e55e24fda9af3f6364319cce3f60116b#diff-4011a114c75fe804332139868806cbe23f275963e4e6afa9b57e51b2b98

As for Meson builds, we did explore them earlier but encountered some issues. Here are some issues/fixes we submitted to the meson community
  https://github.com/mesonbuild/meson/issues/14334
For now, we would like to focus initially on the regular gmake build since our buildfarms predominantly use it. That said, we do plan to submit Meson-related changes as a separate patch in the future. 

Looking forward to your feedback.

-Sriram

---

From: Andres Freund <[email-masked]>
Date: Mon, 22 Sep 2025 08:27:04 -0400

Hi,

On 2025-09-22 11:09:53 +0000, AIX PG user wrote:
> As for Meson builds, we did explore them earlier but encountered some
> issues. Here are some issues/fixes we submitted to the meson community
> https://github.com/mesonbuild/meson/issues/14334 For now, we would like to
> focus initially on the regular gmake build since our buildfarms
> predominantly use it. That said, we do plan to submit Meson-related changes
> as a separate patch in the future.

I think we should do the opposite if anything. We're planning to eventually
remove make based builds.

But I'm also suprprised - before the removal meson based builds on AIX were
working. Why didn't you just revive it as it was?

Greetings,

Andres Freund

---

From: AIX PG user <[email-masked]>
Date: Tue, 23 Sep 2025 14:26:08 +0000

Hi Andres,
Thank you for your feedback and for highlighting the importance of Meson-based builds.

We fully recognize the long-term objective of transitioning away from
make-based builds, and we are actively working on reviving Meson support for
AIX in alignment with that direction. However, we are currently encountering a
few errors with the revived changes, and we are working actively to
resolve them. I will keep you updated and share the finalized Meson-related
changes at the earliest opportunity.

In the meantime, we would sincerely appreciate it if you/team could review the patch
with respect to the gmake build and the associated source-level modifications
submitted on commitfest.
    https://commitfest.postgresql.org/patch/6050/

Your input would be invaluable in helping us ensure the correctness and
completeness of the implementation before we proceed further.  Thank you once
again for your continued guidance and support.

Warm regards,
Sriram.

---

From: Andres Freund <[email-masked]>
Date: Tue, 23 Sep 2025 10:36:47 -0400

Hi,

> changes at the earliest opportunity.

It worked without meson changes just before the AIX support was dropped. I do
not see why you *need* that meson patch, rather it just being convenient -
after all I had made it work before, without that.

> with respect to the gmake build and the associated source-level modifications

I'd personally just not add gmake support at all, but ...

> again for your continued guidance and support.

One suggestion I do have is to split the patch into a few constitutent pieces.

Greetings,

Andres Freund

---

From: Srirama Kucherlapati <[email-masked]>
Date: Tue, 23 Sep 2025 15:28:58 +0000

Hi Andres,
> after all I had made it work before, without that.

I was able to build successfully using Meson on PostgreSQL 16. However, when attempting the same on the latest master(with the revived changes), I encountered a few errors. We are currently investigating these issues and working on the necessary fixes.
I’ll keep you updated once the Meson-related fixes are ready.

> One suggestion I do have is to split the patch into a few constitutent pieces.
Thank you for the suggestion.
Splitting the patch into smaller, constituent pieces makes sense and would certainly help with clarity and review.
Appreciate your guidance.

Warm regards,
Sriram.