Re: AIX support

I thought it might be a good idea to take a step back and survey the
landscape for this patch. Back when we decided to drop AIX support
for v17, several senior hackers opined that we ought to kill it off
permanently, eg Noah said "There's no way forward in which AIX support
stops doing net harm" [1] and Andres said "The only platform rivalling
AIX on the pain-caused metric is windows. And at least that can be
tested via CI (or locally). We've been relying on the gcc buildfarm
to be able to maintain AIX at all, and that's not a resource that
scales to many users" [2]. Have things really changed enough to
justify reversing those opinions?

I think perhaps they have, based on these things:

1. AIX 7.1 is now EOL, and people seem comfortable with not
re-supporting it.

2. People also seem comfortable with only supporting gcc not xlr
(and reasonably late-model gcc, to avoid some old bugs therein).
We are probably also okay with only supporting 64-bit builds.

3. We have a buildfarm animal running AIX 7.3 (douc); currently
it only builds the pre-v17 branches, but that is easy to adjust
once a patch lands. It'd be better if douc were using
--enable-tap-tests, but at least it's there.

4. We have some support now from IBM people.

I looked through the specific pain points that have been mentioned
in this thread and others, and most though not all seem to be
solved or soluble in this landscape. Past problems include:

* failure to honor PG_IO_ALIGN_SIZE on a static variable
https://www.postgresql.org/message-id/20240224172345.32%40rfd.leadboat.com
My testing says this is fixed in AIX 7.3.

* xlc codegen bugs affecting timetz
https://postgr.es/m/CA+hUKGK=DOC+hE-62FKfZy=Ybt5uLkrg3zCZD-jFykM-iPn8yw%40mail.gmail.com
Dropping xlc support resolves this (and some other problems I've
not bothered to list here).

Live problems with the current patch include:

* int8 vs float8 alignment issue
The configure changes in the present patch are hacky, and worse they
do not solve the problem: we'd still need weird coding rules for any
float8 column in the system catalogs. I have a proposal here:
https://www.postgresql.org/message-id/flat/1127261.1769649624%40sss.pgh.pa.us
which is reasonably clean code-wise but would force a dump-and-reload
rather than pg_upgrade to go from <= v16 to v19. Is that good enough?

* s_lock.h changes: it's not okay to change anything affecting non-AIX
I've done a little research on this topic, which I'll include in a
separate message.

* -D_H_FLOAT hack
This should no longer be necessary after Michael's commit d46aa32ea.

* do we really still need mkldexport.sh?
I can understand people's distaste for this, but in the big scheme
of things I don't find it to be a showstopper. It'd be nice if
someone who's familiar with the relevant AIX tools would annotate
it with some comments explaining what it's doing, though.

* assorted random changes in the meson.build files
What we had before 0b16bb877 worked; it didn't support xlc but that's
now moot. So it's not clear why this patch is introducing things
like dep_static_lib, and the lack of comments about that doesn't help.

* patch is missing documentation, ps_status.c, and a few other fixes
This stuff does not seem like a major amount of work, but it does
need to get done.

So, with the possible exception of the int8/float8 alignment issue,
it seems to me we're within striking distance of a committable patch.

I wonder whether anyone still wants to argue that AIX support is
unsustainable on these terms. My own opinion is that it's probably
okay, and we can always rip it out again if IBM fails to follow
through on support from their end.

regards, tom lane

[1] https://www.postgresql.org/message-id/20240225194322.a5%40rfd.leadboat.com
[2] https://www.postgresql.org/message-id/20240229093531.zc5bpnfhpwz5fulx%40alap3.anarazel.de