Re: AIX support

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "tvk1271@gmail.com" <tvk1271@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2024-04-26T17:04:13Z
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 Thu, Apr 25, 2024 at 10:16:34AM +0200, Álvaro Herrera wrote:
> On 2024-Apr-24, Bruce Momjian wrote:
> 
> > 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.
> 
> I'm not sure how large the demand would be for an AIX port specifically
> of 17, though.  I mean, people using older versions can continue to use
> 16 until 18 is released.  Upgrading past one major version is hardly
> unheard of.

Agreed.  They seem to have packages for 11/12, and only 15 recently.  I
don't see how PG 17 would be missed, unless there are many people
compiling from source.

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

  Only you can decide what is important to you.