Re: AIX support

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>

To: Sriram RK <sriram.rk@outlook.com>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>

Cc: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "tvk1271@gmail.com" <tvk1271@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>

Date: 2024-04-20T15:42:03Z

Lists: pgsql-hackers

Commits

Same data as JSON: 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 19.04.24 13:04, Sriram RK wrote:
> 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.

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.