Re: AIX support

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Srirama Kucherlapati <sriram.rk@in.ibm.com>, Peter Eisentraut <peter@eisentraut.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Cc: Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, "tvk1271@gmail.com" <tvk1271@gmail.com>, postgres-ibm-aix <postgres-ibm-aix-dg@ibm.com>, Sriram RK <sriram.rk@outlook.com>
Date: 2024-05-23T16:03:20Z
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 →
  1. Restore AIX support.

  2. pg_createsubscriber: Improve error messages.

  3. Use <stdint.h> and <inttypes.h> for c.h integers.

  4. Stabilize jsonb_path_query test case.

  5. Fix C23 compiler warning

  6. pg_stat_statements: Add tests for nested queries with level tracking

  7. Add missing newline at the end of index_including.sql

  8. Remove AIX support

  9. Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.

  10. Use a non-locking initial test in TAS_SPIN on PPC.

  11. Use LWSYNC in place of SYNC/ISYNC in PPC spinlocks, where possible.

  12. Use mutex hint bit in PPC LWARX instructions, where possible.

  13. Adjust TAS assembly as per recent discussions: use "+m"(*lock) everywhere

  14. Apple's assembler likes the inlined TAS syntax too, so no reason to

  15. Tighten up register usage for inline PPC version of tas().

  16. Put the isync where it's supposed to be.

  17. > > I'll re-check that with the ppc architecture guy here.

  18. Fix PPC s_lock operations to work correctly on multi-CPU machines.

  19. I tried to build PostgreSQL with the following step to see backends hung

  20. Complete merge of all old man page information.

  21. s_lock aix patch.

On 23/05/2024 18:36, Srirama Kucherlapati wrote:
> Hi Peter, thanks for your feedback.
> 
> We are eager to extend our support in resolving the issues specific 
> to AIX or corresponding compilers (XLC and cLang).
> 
> But as there are no issues with the patch after reverting the 
> changes(with the latest compilers gcc12 and xlc-16.0.1.18), we were 
> wondering if this patch can be merged with the current release 17??
> 
> Having said that, we are committed to resolve all the hacks and 
> caveats that got accumulated specific to AIX over the period by 
> picking and resolving one after the other, rather than waiting for 
> all the hacks to be fixed.

I'm not eager to put back those hacks just to have them be removed
again. So I'd like to see a minimal patch, with the *minimal* changes
required for AIX support. And perhaps split that into two patches: First
add back AIX support with GCC, and second patch to add XLC support. I'd
like to to see how much of the changes are because of the different
compiler and how much from the OS.

No promises for v17, but if the patch is small and non-intrusive, I
would consider it at least. But let's see what it looks like first. It's
the same work that needs to be done whether it goes into v17 or v18 anyway.

>> One of the reasons that the AIX port ultimately became 
>> unmaintainable was that so many hacks and caveats were accumulated
>> over the years.  A new port should set a more recent baseline and
>> trim all those hacks.
> 
> Please help me understand this, with respect to the AIX specific 
> hacks, is it just we can find all the location where _AIX macros are 
> involved OR can we just look at the patch changes only, as all the 
> changes that were made were specific to AIX. If not, is there any 
> other location where we could find all the hacks to be resolved.
> 
> Can you provide some more details on the expectations here?

Smallest possible patch that makes Postgres work on AIX again.

Perhaps start with the patch you posted yesterday, but remove hunks from 
it one by one, to see which ones are still needed.

-- 
Heikki Linnakangas
Neon (https://neon.tech)