Re: AIX support
Tom Lane <tgl@sss.pgh.pa.us>
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
Peter Eisentraut <peter@eisentraut.org> writes: > 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. Yup, that's a totally fair complaint. Still ... > 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. 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