Re: AIX support
Thomas Munro <thomas.munro@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restore AIX support.
- 4a1b05caa55d 19 (unreleased) landed
-
pg_createsubscriber: Improve error messages.
- 898c131b58a0 18.0 cited
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 cited
-
Stabilize jsonb_path_query test case.
- af2115226831 18.0 cited
-
Fix C23 compiler warning
- d2b4b4c2259e 18.0 cited
-
pg_stat_statements: Add tests for nested queries with level tracking
- 45e0ba30fc40 18.0 cited
-
Add missing newline at the end of index_including.sql
- 54b69f1bd730 17.0 cited
-
Remove AIX support
- 0b16bb8776bb 17.0 cited
-
Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.
- c41a1215f049 9.6.0 cited
-
Use a non-locking initial test in TAS_SPIN on PPC.
- bc2a050d4097 9.2.0 cited
-
Use LWSYNC in place of SYNC/ISYNC in PPC spinlocks, where possible.
- 631beeac3598 9.2.0 cited
-
Use mutex hint bit in PPC LWARX instructions, where possible.
- 5cfa8dd3007d 9.2.0 cited
-
Adjust TAS assembly as per recent discussions: use "+m"(*lock) everywhere
- 109867748259 8.0.0 cited
-
Apple's assembler likes the inlined TAS syntax too, so no reason to
- f9ba0a7fe563 7.4.1 cited
-
Tighten up register usage for inline PPC version of tas().
- eb5e4c58d137 7.4.1 cited
-
Put the isync where it's supposed to be.
- cd35d601b859 7.4.1 cited
-
> > I'll re-check that with the ppc architecture guy here.
- ceb4f5ea9c2c 7.4.1 cited
-
Fix PPC s_lock operations to work correctly on multi-CPU machines.
- 7233aae50bea 7.3.1 cited
-
I tried to build PostgreSQL with the following step to see backends hung
- 50938576d482 7.3.1 cited
-
Complete merge of all old man page information.
- f2f43efbe1d5 7.1.1 cited
-
s_lock aix patch.
- e3b06a871b63 7.1.1 cited
On Fri, Apr 19, 2024 at 6:01 AM Andres Freund <andres@anarazel.de> wrote: > On 2024-04-18 11:15:43 +0000, Sriram RK wrote: > > We (IBM-AIX team) looked into this issue > > > > https://www.postgresql.org/message-id/20240225194322.a5@rfd.leadboat.com > > > > 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. 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. > 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. 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. > > 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). 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.