Horton

Re: AIX support

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Sriram RK <sriram.rk@outlook.com>
Cc: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "tvk1271@gmail.com" <tvk1271@gmail.com>
Date: 2024-04-18T18:01:28Z
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.

Hi,

On 2024-04-18 11:15:43 +0000, Sriram RK wrote:
> We (IBM-AIX team) looked into this issue
>
> https://www.postgresql.org/message-id/20240225194322.a5@rfd.leadboat.com
>
> This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
> have issues. But we verified that this issue is resolved with the newer
> compiler versions openXL(xlc17.1) and gcc(12.0) onwards.

The reason we used these compilers was that those were the only ones we had
kinda somewhat reasonable access to, via the gcc projects'
"compile farm" https://portal.cfarm.net/
We have to rely on whatever the aix machines there provide. They're not
particularly plentiful resource-wise either.


This is generally one of the big issues with AIX support. There are other
niche-y OSs that don't have a lot of users, e.g. openbsd, but in contrast to
AIX I can just start an openbsd VM within a few minutes and iron out whatever
portability issue I'm dealing with.

Not being AIX customers we also can't raise bugs about compiler bugs, so we're
stuck doing bad workarounds.


> Also as part of the support, we will help in fixing all the issues related
> to AIX and continue to support AIX for Postgres. If we need another CI
> environment we can work to make one available. But for time being can we
> start reverting the patch that has removed AIX support.

The state when was removed was not in a state that I am OK with adding back.


> We want to make a note that postgres is used extensively in our IBM product
> and is being exploited by multiple customers.

To be blunt: Then it'd have been nice to see some investment in that before
now. Both on the code level and the infrastructure level (i.e. access to
machines etc).

Greetings,

Andres Freund