Re: AIX support

From: Sriram RK <sriram(dot)rk(at)outlook(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tvk1271(at)gmail(dot)com" <tvk1271(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: AIX support
Date: 2024-04-22 10:12:23
Message-ID: CY5PR11MB639299ED14FA718C9739505FFD122@CY5PR11MB6392.namprd11.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Team,

> 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.

We would really like to thank you & the team for considering our request,

and really appreciate for providing all the possible options to support AIX.

> 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.

As we already validated that these alignment specific issues are resolved

with the latest versions of the compilers (gcc/ibm-clang). We would request

you to use the latest versions for the build.

> 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 back branches, like in a

> week. Which seems tight.

We are already working with the internal team in procuring the nodes

for the buildfarm, which can be accessible by the community.

> 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.

We would really appreciate you for providing the possible options

and we are very much inclined to these above approaches.

Regards,

Sriram.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-04-22 10:22:23 Re: cataloguing NOT NULL constraints
Previous Message Alexander Lakhin 2024-04-22 10:00:00 Re: Avoid orphaned objects dependencies, take 3