Re: AIX support

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: 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-25T03:39:37Z

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 Sat, Apr 20, 2024 at 12:25:47PM -0400, Tom Lane wrote:
> > 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.

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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.