Re: AIX support

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Bruce Momjian <bruce@momjian.us>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter@eisentraut.org>, Sriram RK <sriram.rk@outlook.com>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Noah Misch <noah@leadboat.com>, 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-25T04:06:24Z

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 Wed, Apr 24, 2024 at 11:39:37PM -0400, Bruce Momjian wrote:
> On Sat, Apr 20, 2024 at 12:25:47PM -0400, Tom Lane wrote:
>> 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.
> 
> 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.

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