Re: AIX support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AIX support
Date
Msg-id 2476719.1713630347@sss.pgh.pa.us
Whole thread Raw
In response to Re: AIX support  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: AIX support
Re: AIX support
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: AIX support
Next
From: Tom Lane
Date:
Subject: Re: Performance of JSON_TABLE vs jsonb_to_recordset