Subject: Re: AIX support

From: Thomas Munro <[email-masked]>
Date: Fri, 29 Mar 2024 16:14:37 +1300

On Fri, Mar 29, 2024 at 4:00 PM Thomas Munro <[email-masked]> wrote:
> On Fri, Mar 29, 2024 at 3:48 PM Noah Misch <[email-masked]> wrote:
> > 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.
>
> For the specific issue that triggered that, I strongly suspect that it
> would go away if we just used smgrzeroextend() instead of smgrextend()
> using that variable with the alignment requirement, since, as far as I
> can tell from build farm clues, the otherwise similar function-local
> static variable used by the former (ie one that the linker must still
> control the location of AFAIK?) seems to work fine.

Oh, sorry, I had missed the part where newer compilers fix the issue
too.  Old out-of-support versions of AIX running old compilers, what
fun.

---

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

> too.  Old out-of-support versions of AIX running old compilers, what

Indeed.  One of the topics that needs investigation if you want to
pursue this is which AIX system and compiler versions still deserve
support, and which of the AIX hacks we had been carrying still need
to be there based on that analysis.  For context, we've been pruning
support for extinct-in-the-wild OS versions pretty aggressively
over the past couple of years, and I'd expect to apply the same
standard to AIX.

			regards, tom lane

---

From: Sriram RK <[email-masked]>
Date: Fri, 5 Apr 2024 16:12:06 +0000

> 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

Hi Team, thank you for all the info.

We progressed to build the source on our nodes and the build was successful with the below configuration.

Postgres              - github-bcdfa5f2e2f
AIX                         - 71c
Xlc                         - 13.1.0
Bison                    - 3.0.5

Going ahead, we want to build the changes that were removed as part of “0b16bb8776bb8”, with latest Xlc and gcc version.

We were building the source from the postgres ftp server(https://ftp.postgresql.org/pub/source/), would like to understand if there are any source level changes between the ftp server and the source on github?

Regards,
Sriram.

From: Tom Lane <[email-masked]>
Date: Friday, 29 March 2024 at 9:03 AM
To: Thomas Munro <[email-masked]>
Cc: Noah Misch <[email-masked]>, Sriram RK <[email-masked]>, Alvaro Herrera <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: AIX support

                        regards, tom lane

---

From: Noah Misch <[email-masked]>
Date: Fri, 5 Apr 2024 10:26:49 -0700

> We were building the source from the postgres ftp server(https://ftp.postgresql.org/pub/source/), would like to understand if there are any source level changes between the ftp server and the sourc…

To succeed in this endeavor, you'll need to develop fluency in the tools to
answer questions like that, or bring in someone who is fluent.  In this case,
GNU diff is the standard tool for answering your question.  These resources
cover other topics you would need to learn:

https://wiki.postgresql.org/wiki/Developer_FAQ
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F

---

From: Sriram RK <[email-masked]>
Date: Thu, 18 Apr 2024 11:15:43 +0000

Thanks Noah and Team,

We (IBM-AIX team) looked into this issue

https://www.postgresql.org/message-id/[email-masked]

This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0) have issues. But we verified that this issue is resolved with the newer compiler versions openXL(xlc17.1) and gcc(12.0) onwards.

We reported this issue to the xlc team and they have noted this issue. A fix might be possible in May for this issue in xlc v16.  We would like to understand if the community can start using the latest compilers to build the source.

Also as part of the support, we will help in fixing all the issues related to AIX and continue to support AIX for Postgres. If we need another CI environment we can work to make one available. But for time being can we start reverting the patch that has removed AIX support.

We want to make a note that postgres is used extensively in our IBM product and is being exploited by multiple customers.

Please let us know if there are any specific details you'd like to discuss further.

Regards,
Sriram.

---

From: Heikki Linnakangas <[email-masked]>
Date: Thu, 18 Apr 2024 14:25:23 +0300

>Also as part of the support, we will help in fixing all the issues related to AIX and continue to support AIX for Postgres. If we need another CI environment we can work to make one available. But f…

Let's start by setting up a new AIX buildfarm member. Regardless of what we do with v17, we continue to support AIX on the stable branches, and we really need a buildfarm member to keep the stable branches working anyway.

>We want to make a note that postgres is used extensively in our IBM product and is being exploited by multiple customers.

Noted. I'm glad to hear you are interested to put in some effort for this. The situation from the current maintainers is that none of us have much interest, or resources or knowledge to keep the AIX build working, so we'll definitely need the help.

No promises on v17, but let's at least make sure the stable branches keep working. And with the patches and buildfarm support from you, maybe v17 is feasible too.

- Heikki

---

From: Sriram RK <[email-masked]>
Date: Thu, 18 Apr 2024 11:57:48 +0000

> Let's start by setting up a new AIX buildfarm member. Regardless of what we do with v17, we continue to support AIX on the stable branches, and we really need a buildfarm member to keep the stable…

Thanks Heikki. We had already build the source code(v17+ bcdfa5f2e2f) on our local nodes. We will try to setup the buildfarm and let you know.
Is there any specific configuration we are looking for?

Regards,
Sriram.

---

From: Andres Freund <[email-masked]>
Date: Thu, 18 Apr 2024 11:01:28 -0700

Hi,

On 2024-04-18 11:15:43 +0000, Sriram RK wrote:
> This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> have issues. But we verified that this issue is resolved with the newer
> compiler versions openXL(xlc17.1) and gcc(12.0) onwards.

The reason we used these compilers was that those were the only ones we had
kinda somewhat reasonable access to, via the gcc projects'
"compile farm" https://portal.cfarm.net/
We have to rely on whatever the aix machines there provide. They're not
particularly plentiful resource-wise either.

This is generally one of the big issues with AIX support. There are other
niche-y OSs that don't have a lot of users, e.g. openbsd, but in contrast to
AIX I can just start an openbsd VM within a few minutes and iron out whatever
portability issue I'm dealing with.

Not being AIX customers we also can't raise bugs about compiler bugs, so we're
stuck doing bad workarounds.

> Also as part of the support, we will help in fixing all the issues related
> to AIX and continue to support AIX for Postgres. If we need another CI
> environment we can work to make one available. But for time being can we
> start reverting the patch that has removed AIX support.

The state when was removed was not in a state that I am OK with adding back.

> We want to make a note that postgres is used extensively in our IBM product
> and is being exploited by multiple customers.

To be blunt: Then it'd have been nice to see some investment in that before
now. Both on the code level and the infrastructure level (i.e. access to
machines etc).

Greetings,

Andres Freund

---

From: Thomas Munro <[email-masked]>
Date: Fri, 19 Apr 2024 12:40:12 +1200

> particularly plentiful resource-wise either.

To be fair, those OSUOSL machines are donated by IBM:

https://osuosl.org/services/powerdev/

It's just that they seem to be mostly focused on supporting Linux on
POWER, with only a couple of AIX hosts (partitions/virtual machines?)
made available via portal.cfarm.net, and they only very recently added
a modern AIX 7.3 host. That's cfarm119, upgraded in September-ish,
long after many threads on this list that between-the-lines threatened
to drop support.

> portability issue I'm dealing with.

Yeah.  It is a known secret that you can run AIX inside Qemu/kvm (it
appears that IBM has made changes to it to make that possible, because
earlier AIX versions didn't like Qemu's POWER emulation or
virtualisation, there are blog posts about it), but IBM doesn't
actually make the images available to non-POWER-hardware owners (you
need a serial number).  If I were an OS vendor and wanted developers
to target my OS for free, at the very top of my TODO list I would
have: provide an easy to use image for developers to be able to spin
something up in minutes and possibly even use in CI systems.  That's
the reason I can fix any minor portability issue on Linux, illumos,
*BSD quickly and Windows with only moderate extra pain.  Even Oracle
knows this, see Solaris CBE.

> now. Both on the code level and the infrastructure level (i.e. access to

In the AIX space generally, there were even clues that funding had
been completely cut even for packaging PostgreSQL.  I was aware of two
packaging projects (not sure how they were related):

1.  The ATOS packaging group, who used to show up on our mailing lists
and discuss code changes, which announced it was shutting down:

https://github.com/power-devops/bullfreeware

2.  And last time I looked a few months back, the IBM AIX Toolbox
packaging project only had PostgreSQL 10 or 11 packages, already out
of support by us, meaning that their maintainer had given up, too:

https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads-alpha

However I see that recently (last month?) someone has added PostgreSQL
15, so something has only just reawoken there?

There are quite a lot of threads about AIX problems, but they are
almost all just us non-AIX-users trying to unbreak stupid stuff on the
build farm, which at some points began to seem distinctly quixotic:
chivalric hackers valiantly trying to keep the entire Unix family tree
working even though we don't remember why and th versions involved are
out of support even by the vendor.  Of the three old giant commercial
Unixes, HP-UX was dropped without another mention (it really was a
windmill after all), Solaris is somehow easier to deal with (I could
guess it's because it influenced Linux and BSD so much, ELF and linker
details spring to mind), while AIX fails on every dimension:
unrepresented by users, lacking in build farm, unavailable to
non-customers, and unusual among Unixen.

---

From: Sriram RK <[email-masked]>
Date: Fri, 19 Apr 2024 11:04:07 +0000

For any complier/hardware related issue we should able to provide support.
We are in the process of identifying the AIX systems that can be added to the CI/buildfarm environment.

Regards,
Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Sat, 20 Apr 2024 17:42:03 +0200

> to the CI/buildfarm environment.

I think we should manage expectations here, if there is any hope of 
getting AIX support back into PG17.

I have some sympathy for this.  The discussion about removing AIX 
support had a very short turnaround and happened in an unrelated thread, 
without any sort of public announcement or consultation.  So this report 
of "hey, we were still using that" is timely and fair.

But the underlying issue that led to the removal (something to do with 
direct I/O support and alignment) would still need to be addressed.  And 
this probably wouldn't just need some infrastructure support; it would 
require contributions from someone who actively knows how to develop on 
this platform.  Now, direct I/O is currently sort of an experimental 
feature, so disabling it on AIX, as was initially suggested in that 
discussion, might be okay for now, but the issue will come up again.

Even if this new buildfarm support is forthcoming, there has to be some 
sort of deadline in any resurrection attempts for PG17.  The first beta 
date has been set for 23 May.  If we are making the reinstatement of AIX 
support contingent on new buildfarm support, those machines need to be 
available, at least initially, at least for backbranches, like in a 
week.  Which seems tight.

I can see several ways going forward:

1. We revert the removal of AIX support and carry on with the status quo 
ante.  (The removal of AIX is a regression; it is timely and in scope 
now to revert the change.)

2. Like (1), but we consider that notice has been given, and we will 
remove it early in PG18 (like August) unless the situation improves.

3. We leave it out of PG17 and consider a new AIX port for PG18 on its 
own merits.

Note that such a "new" port would probably require quite a bit of 
development and research work, to clean up all the cruft that had 
accumulated over the years in the old port.  Another looming issue is 
that the meson build system only supported AIX with gcc before the 
removal.  I don't know what it would take to expand that to support 
xclang, but if it requires meson upstream work, you have that to do, too.

---

From: Tom Lane <[email-masked]>
Date: Sat, 20 Apr 2024 12:25:47 -0400

> of "hey, we were still using that" is timely and fair.

Yup, that's a totally fair complaint.  Still ...

> 3. We leave it out of PG17 and consider a new AIX port for PG18 on its 

Andres has ably summarized the reasons why the status quo ante was
getting untenable.  The direct-I/O problem could have been tolerable
on its own, but in reality it was the straw that broke the camel's
back so far as our willingness to maintain AIX support went.  There
were just too many hacks and workarounds for too many problems,
with too few people interested in looking for better answers.

So I'm totally not in favor of #1, at least not without some hard
commitments and follow-through on really cleaning up the mess
(which maybe looks more like your #2).  What's needed here, as
you said, is for someone with a decent amount of expertise in
modern AIX to review all the issues.  Maybe framing that as a
"new port" per #3 would be a good way to think about it.  But
I don't want to just revert the AIX-ectomy and continue drifting.

On the whole, it wouldn't be the worst thing in the world if PG 17
lacks AIX support but that comes back in PG 18.  That approach would
solve the schedule-crunch aspect and give time for considered review
of how many of the hacks removed in 0b16bb877 really need to be put
back, versus being obsolete or amenable to a nicer solution in
late-model AIX.  If we take a "new port" mindset then it would be
totally reasonable to say that it only supports very recent AIX
releases, so I'd hope at least some of the cruft could be removed.

			regards, tom lane

---

From: Sriram RK <[email-masked]>
Date: Mon, 22 Apr 2024 10:12:23 +0000

Hi Team,

> of "hey, we were still using that" is timely and fair.

    We would really like to thank you & the team for considering our request,

    and really appreciate for providing all the possible options to support AIX.

> direct I/O support and alignment) would still need to be addressed.

    As we already validated that these alignment specific issues are resolved

    with the latest versions of the compilers (gcc/ibm-clang). We would request

    you to use the latest versions for the build.

> If we are making the reinstatement of AIX

> available, at least initially, at least for back branches, like in a

> week. Which seems tight.

    We are already working with the internal team in procuring the nodes

    for the buildfarm, which can be accessible by the community.

> remove it early in PG18 (like August) unless the situation improves.

    We would really appreciate you for providing the possible options

    and we are very much inclined to these above approaches.

Regards,

Sriram.

---

From: "Tristan Partin" <[email-masked]>
Date: Mon, 22 Apr 2024 09:54:50 -0500

> xclang, but if it requires meson upstream work, you have that to do, too.

Happy to help advocate for any PRs from AIX folks on the Meson side. You 
can find me as @tristan957 on github.

-- 
Tristan Partin
Neon (https://neon.tech)

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 24 Apr 2024 23:39:37 -0400

> releases, so I'd hope at least some of the cruft could be removed.

I agree that targeting PG 18 for a new-er AIX port is the reasonable
approach.  If there is huge demand, someone can create an AIX fork for
PG 17 using the reverted patches --- yeah, lots of pain there, but we
have carried the AIX pain for too long with too little support.

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

  Only you can decide what is important to you.

---

From: Michael Paquier <[email-masked]>
Date: Thu, 25 Apr 2024 13:06:24 +0900

> have carried the AIX pain for too long with too little support.

Some of the portability changes removed in 0b16bb877 feel indeed
obsolete, so it may not hurt to start an analysis from scratch to see
the minimum amount of work that would be really required with the
latest versions of xlc, using the newest compilers as a supported
base.  I'd like to think backporting these to stable branches should
be OK at some point, once the new port is proving baked enough.

Anyway, getting an access to such compilers to be able to debug issues
on hosts that take less than 12h to just compile the code would
certainly help its adoption.  So seeing commitment in the form of
patches and access to environments would help a lot.  Overall,
studying that afresh with v18 looks like a good idea, assuming that
anybody who commits such patches has access to hosts to evaluate them,
with buildfarm members running on top, of course.

My 2c.
--
Michael

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Apr 2024 00:20:05 -0400

Michael Paquier <[email-masked]> writes:
> base.

Something I've been mulling over is whether to suggest that the
proposed "new port" should only target building with gcc.

On the one hand, that would (I think) remove a number of annoying
issues, and the average end user is unlikely to care which compiler
their database server was built with.  On the other hand, I'm a strong
proponent of avoiding software monocultures, and xlc is one of the few
C compilers still standing that aren't gcc or clang.

It would definitely make sense for a new port to start by getting
things going with gcc only, and then look at resurrecting xlc
support.

> I'd like to think backporting these to stable branches should

If things go as I expect, the "new port" would effectively drop
support for older AIX and/or older compiler versions.  So back-
porting seems like an unlikely decision.

> certainly help its adoption.

+many

			regards, tom lane

---

From: Michael Paquier <[email-masked]>
Date: Thu, 25 Apr 2024 13:45:13 +0900

> things going with gcc only, and then look at resurrecting xlc

Sriram mentioned upthread that he was looking at both of them.  I'd be
ready to assume that most of the interest is in xlc, not gcc.  But I
may be wrong.

Saying that, dividing the effort into more successive steps is
sensible here (didn't consider that previously, you have a good
point).
--
Michael

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 25 Apr 2024 10:03:11 +0200

> C compilers still standing that aren't gcc or clang.

My understanding is that the old xlc is dead and has been replaced by 
"xlclang", which is presumably an xlc-compatible frontend on top of 
clang/llvm.  Hopefully, that will have fewer issues.

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Apr 2024 09:54:22 -0400

> clang/llvm.  Hopefully, that will have fewer issues.

[ googles... ]  Actually it seems to be the other way around:
per [1] xlclang is a clang-based front end to IBM's existing
codegen+optimization logic, and the xlc front end is still there too.
It's not at all clear that they have any intention of killing off xlc.

Not sure where that leaves us in terms of either one being an
interesting target to support.  xlclang is presumably an easier lift
to get working, but that also makes it much less interesting from
the preserve-our-portability standpoint.

			regards, tom lane

[1] https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=new-clang-based-front-end

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 26 Apr 2024 13:06:12 -0400

> with buildfarm members running on top, of course.

Agreed.  They can't even have buildfarm member for PG 17 since it
doesn't compile anymore, so someone has to go over the reverted patch,
figure out which ones are still valid, and report back.  Trying to add a
port, with possible breakage, during beta seems too risky compared to
the value.

---

From: Sriram RK <[email-masked]>
Date: Fri, 26 Apr 2024 17:30:00 +0000

> ready to assume that most of the interest is in xlc, not gcc.  But I

Just a heads-up, we got a node in the OSU lab for the buildfarm. Will let you know once we have the buildfarm setup on that node.

Also, we are making progress on setting up the buildfarm on a local node as well.
But currently there are some tests failing, seems some issue with plperl.

                aix01::build-farm-17#
./run_build.pl --keepall  --nosend --nostatus --verbose=5  --force REL_16_STABLE

Fri Apr 26 00:53:50 2024: buildfarm run for AIXnode01:REL_16_STABLE starting
AIXnode01:REL_16_STABLE [00:53:50] checking out source ...
AIXnode01:REL_16_STABLE [00:53:56] checking if build run needed ...
AIXnode01:REL_16_STABLE [00:53:56] copying source to pgsql.build ...
AIXnode01:REL_16_STABLE [00:54:08] running configure ...
AIXnode01:REL_16_STABLE [00:55:01] running build ...
AIXnode01:REL_16_STABLE [01:08:09] running basic regression tests ...
AIXnode01:REL_16_STABLE [01:09:51] running make contrib ...
AIXnode01:REL_16_STABLE [01:11:08] running make testmodules ...
AIXnode01:REL_16_STABLE [01:11:19] running install ...
AIXnode01:REL_16_STABLE [01:11:48] running make contrib install ...
AIXnode01:REL_16_STABLE [01:12:01] running testmodules install ...
AIXnode01:REL_16_STABLE [01:12:06] checking test-decoding
gmake: gcc: A file or directory in the path name does not exist.
AIXnode01:REL_16_STABLE [01:12:28] running make check miscellaneous modules ...
gmake: gcc: A file or directory in the path name does not exist.
AIXnode01:REL_16_STABLE [01:13:50] setting up db cluster (C)...
AIXnode01:REL_16_STABLE [01:13:53] starting db (C)...
AIXnode01:REL_16_STABLE [01:13:53] running installcheck (C)...
AIXnode01:REL_16_STABLE [01:15:05] restarting db (C)...
AIXnode01:REL_16_STABLE [01:15:07] running make isolation check ...
AIXnode01:REL_16_STABLE [01:15:51] restarting db (C)...
AIXnode01:REL_16_STABLE [01:15:56] running make PL installcheck (C)...
Branch: REL_16_STABLE
Stage PLCheck-C failed with status 2

---

From: Sriram RK <[email-masked]>
Date: Sat, 4 May 2024 16:01:06 +0000

Hi Team,

There are couple of updates, firstly we got an AIX node on the OSU lab.
Please feel free to reach me, so that we can provide access to the node.
We have started working on setting up the buildfarm on that node.

Secondly, as part of the buildfarm setup on our local nodes, we are hitting
an issue with the plperl extension. In the logs we noticed that when the
plperl extension is being created, it is failing to load the perl library.

    - CREATE EXTENSION plperlu;
    + server closed the connection unexpectedly
    +       This probably means the server terminated abnormally
    +       before or while processing the request.
    + connection to server was lost

In the logfile we could see these

    2024-05-04 05:05:17.537 CDT [3997786:17] pg_regress/plperl_setup LOG:  statement: CREATE EXTENSION plperl;
    Util.c: loadable library and perl binaries are mismatched (got first handshake key 9b80080, needed 9a80080)

We tried to resolve some of the suggestions mentioned here, but things couldn’t resolve.

https://www.postgresql.org/message-id/CALDaNm15qaRFb3WiPFAdFqoB9pj1E5SCPPUGB%2BnJ4iF4gXO6Rw%40mail.gmail.com

Any inputs here would be greatly appreciated.

Regards,
Sriram.

---

From: Sriram RK <[email-masked]>
Date: Mon, 6 May 2024 14:12:22 +0000

Hi Team, on further investigation we were able to resolve the perl issue by setting the right PERL env location. Earlier it was pointing to the 32bit perl, as a result the perl lib mismatch seems to be happening.
Now we have successfully built release 15 and 16 stable branches on the OSU lab node.

p9aix (OSU)
OS: AIX 72Z
    RELEASE 16
    p9aix:REL_16_STABLE [08:31:26] OK
    ======== log passed to send_result ===========
    Branch: REL_16_STABLE
    All stages succeeded

    RELEASE 15
    p9aix:REL_15_STABLE [08:55:37] OK
    ======== log passed to send_result ===========
    Branch: REL_15_STABLE
    All stages succeeded

Also, we had successfully built release 16 branch on our local nodes as well
OS: AIX 71C
    pgsql-aix71C:REL_16_STABLE [02:25:32] OK
    ======== log passed to send_result ===========
    Branch: REL_16_STABLE
    All stages succeeded

OS: AIX72Z
    pgsql-aix72Z:REL_16_STABLE [02:35:03] OK
    ======== log passed to send_result ===========
    Branch: REL_16_STABLE
    All stages succeeded

OS: AIX73D
    pgsql-aix73D:REL_16_STABLE [05:32:29] OK
    ======== log passed to send_result ===========
    Branch: REL_16_STABLE
    All stages succeeded

Regards,
Sriram.

---

From: Sriram RK <[email-masked]>
Date: Wed, 8 May 2024 11:39:17 +0000

Hi Team, We have the AIX node ready in OSU lab, and the branches 15 and 16 got build on the node. We had raised a request to register this node as buildfarm member. Yet to receive the approval.

We would like to understand your inputs/plans on reverting the changes for AIX.

Thanks,
Sriram.

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 8 May 2024 15:44:12 +0200

> We would like to understand your inputs/plans on reverting the changes 

I think the ship has sailed for PG17.  The way forward would be that you 
submit a patch for new, modernized AIX support for PG18.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 8 May 2024 10:06:53 -0400

> submit a patch for new, modernized AIX support for PG18.

Yes, I think we were clear that someone needs to review the reverted
patch and figure out which parts are still needed, and why.  We have no
"plans" to restore support.

---

From: Sriram RK <[email-masked]>
Date: Wed, 15 May 2024 15:33:25 +0000

Hi Team, we have any updated from the XLC team, the issue specific to the alignment is fixed
and XLC had released it as part of 16.1.0.18. The PTF is available at the below location,

You can also find a link here:
https://www.ibm.com/support/pages/fix-list-xl-cc-aix.

>>/opt/IBM/xlC/16.1.0/bin/xlC align.c -o align.xl

>>./align.xl
al4096                           4096 @ 0x20008000 (mod 0)
al4096_initialized               4096 @ 0x20004000 (mod 0)
al4096_const                     4096 @ 0x2000b000 (mod 0)
al4096_const_initialized         4096 @ 0x10008000 (mod 0)
al4096_static                    4096 @ 0x2000e000 (mod 0)
al4096_static_initialized        4096 @ 0x20001000 (mod 0)
al4096_static_const              4096 @ 0x20011000 (mod 0)
al4096_static_const_initialized  4096 @ 0x10001000 (mod 0)

Also would like to know some info related to the request raised for buildfarm access, to register the node in OSU lab. Where can I get the status of the request? Whom can I contact to get the request approved? So that we can add the node to the buildfarm.

Regards,
Sriram.

---

From: Noah Misch <[email-masked]>
Date: Wed, 15 May 2024 08:52:41 -0700

> al4096_static_const_initialized  4096 @ 0x10001000 (mod 0)

That is good news.  PGIOAlignedBlock is now in the IBM publication,
https://www.ibm.com/support/pages/apar/IJ51032

> Also would like to know some info related to the request raised for buildfarm access, to register the node in OSU lab. Where can I get the status of the request? Whom can I contact to get the reque…

I assume you filled out the form at
https://buildfarm.postgresql.org/cgi-bin/register-form.pl?  It can take a few
weeks, so I wouldn't worry yet.

---

From: Sriram RK <[email-masked]>
Date: Wed, 15 May 2024 16:22:10 +0000

> > Also would like to know some info related to the request raised for buildfarm access, to register the
> > node in OSU lab. Where can I get the status of the request? Whom can I contact to get the request
> > approved? So that we can add the node to the buildfarm.

> weeks, so I wouldn't worry yet.

Thanks Noha, I had already submitted a form a week back, hope it might take another couple of weeks to get it approved.

---

From: Sriram RK <[email-masked]>
Date: Thu, 16 May 2024 14:17:38 +0000

Hi Team,

We have an update wrt to the PG17 AIX port.

We have reverted the changes specific to AIX (that were removed in 0b16bb8776bb8) to the latest PG17 (head).

The Buildfarm succeeded for these changes. All the tests passed.

    System config

          OS level : AIX-73D

          Compiler : gcc-12 & xlc(16.1.0.18)

    Wed May 15 21:26:00 2024: buildfarm run for AIXnode01:HEAD starting

    AIXnode01:HEAD          [21:26:00] running configure ...

    AIXnode01:HEAD          [21:27:03] running build ...

    AIXnode01:HEAD          [21:27:27] running basic regression tests ...

    AIXnode01:HEAD          [21:34:41] running make contrib ...

    AIXnode01:HEAD          [21:34:43] running make testmodules ...

    AIXnode01:HEAD          [21:34:44] running install ...

    AIXnode01:HEAD          [21:34:58] running make contrib install ...

    AIXnode01:HEAD          [21:35:05] running testmodules install ...

    AIXnode01:HEAD          [21:35:08] checking pg_upgrade

    AIXnode01:HEAD          [21:35:08] checking test-decoding

    AIXnode01:HEAD          [21:35:29] running make check miscellaneous modules ...

    AIXnode01:HEAD          [21:36:16] setting up db cluster (C)...

    AIXnode01:HEAD          [21:36:19] starting db (C)...

    AIXnode01:HEAD          [21:36:19] running installcheck (C)...

    AIXnode01:HEAD          [21:46:27] restarting db (C)...

    AIXnode01:HEAD          [21:46:29] running make isolation check ...

    AIXnode01:HEAD          [21:49:57] restarting db (C)...

    AIXnode01:HEAD          [21:50:02] running make PL installcheck (C)...

    AIXnode01:HEAD          [21:50:09] restarting db (C)...

    AIXnode01:HEAD          [21:50:12] running make contrib installcheck (C)...

    AIXnode01:HEAD          [21:53:53] restarting db (C)...

    AIXnode01:HEAD          [21:53:56] running make test-modules installcheck (C)...

    AIXnode01:HEAD          [21:54:28] stopping db (C)...

    AIXnode01:HEAD          [21:54:29] running make ecpg check ...

    AIXnode01:HEAD          [21:54:45] OK

    Branch: HEAD

    All stages succeeded

The below changes are applied on this commit level

commit 54b69f1bd730a228a666441592a12d2a0cbe2a06 (HEAD -> pgAIX, origin/master, origin/HEAD, master)

    On branch pgAIX

    Changes to be committed:

      (use "git restore --staged <file>..." to unstage)

            new file:   src/backend/port/aix/mkldexport.sh

            new file:   src/include/port/aix.h

            new file:   src/makefiles/Makefile.aix

            new file:   src/template/aix

    Changes not staged for commit:

      (use "git add <file>..." to update what will be committed)

      (use "git restore <file>..." to discard changes in working directory)

            modified:   Makefile

            modified:   config/c-compiler.m4

            modified:   configure

            modified:   configure.ac

            modified:   doc/src/sgml/dfunc.sgml

            modified:   doc/src/sgml/installation.sgml

            modified:   doc/src/sgml/runtime.sgml

            modified:   meson.build

            modified:   src/Makefile.shlib

            modified:   src/backend/Makefile

            modified:   src/backend/meson.build

            modified:   src/backend/storage/buffer/bufmgr.c

            modified:   src/backend/utils/error/elog.c

            modified:   src/backend/utils/misc/ps_status.c

            modified:   src/bin/pg_basebackup/t/010_pg_basebackup.pl

            modified:   src/bin/pg_verifybackup/t/008_untar.pl

            modified:   src/bin/pg_verifybackup/t/010_client_untar.pl

            modified:   src/include/c.h

            modified:   src/include/port/atomics.h

            modified:   src/include/storage/s_lock.h

            modified:   src/interfaces/libpq/Makefile

            modified:   src/interfaces/libpq/meson.build

            modified:   src/port/README

            modified:   src/port/strerror.c

            modified:   src/test/regress/Makefile

            modified:   src/test/regress/expected/sanity_check.out

            modified:   src/test/regress/expected/test_setup.out

            modified:   src/test/regress/regress.c

            modified:   src/test/regress/sql/sanity_check.sql

            modified:   src/test/regress/sql/test_setup.sql

            modified:   src/tools/gen_export.pl

            modified:   src/tools/pginclude/headerscheck

Can you please let us know, the process to post the changes for review?

Regards,
Sriram.

---

From: Alvaro Herrera <[email-masked]>
Date: Thu, 16 May 2024 16:30:22 +0200

> The Buildfarm succeeded for these changes. All the tests passed.

Excellent.

> Can you please let us know, the process to post the changes for review?

Here's some very good advice
https://postgr.es/m/[email-masked]

Regards

-- 
Álvaro Herrera

---

From: Sriram RK <[email-masked]>
Date: Wed, 22 May 2024 16:15:35 +0000

Thanks Alvaro, for the info…

Hi Team,
We referred to the below links to build this patch …
https://wiki.postgresql.org/wiki/Submitting_a_Patch
https://peter.eisentraut.org/blog/2023/05/09/how-to-submit-a-patch-by-email-2023-edition

Please find the attached patch.

Apart from the AIX specific changes, there is a minor change in this file wrt to XLC, below is the error for which we removed inline.
Later, the build and tests passed for both XLC(16.1.0.18) and gcc(12) as well.

  src/backend/storage/buffer/bufmgr.c

  "bufmgr.c", line 811.39: 1506-780 (S) Reference to "RelationGetSmgr" with internal linkage is not allowed within inline definition of "ReadBufferExtended".
  "bufmgr.c", line 811.15: 1506-780 (S) Reference to "ReadBuffer_common" with internal linkage is not allowed within inline definition of "ReadBufferExtended".
  gmake[4]: *** [<builtin>: bufmgr.o] Error 1

Please let us know your feedback.

Thanks,
Sriram.