Re: AIX support
Bruce Momjian <bruce@momjian.us>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restore AIX support.
- 4a1b05caa55d 19 (unreleased) landed
-
pg_createsubscriber: Improve error messages.
- 898c131b58a0 18.0 cited
-
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 cited
-
Stabilize jsonb_path_query test case.
- af2115226831 18.0 cited
-
Fix C23 compiler warning
- d2b4b4c2259e 18.0 cited
-
pg_stat_statements: Add tests for nested queries with level tracking
- 45e0ba30fc40 18.0 cited
-
Add missing newline at the end of index_including.sql
- 54b69f1bd730 17.0 cited
-
Remove AIX support
- 0b16bb8776bb 17.0 cited
-
Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.
- c41a1215f049 9.6.0 cited
-
Use a non-locking initial test in TAS_SPIN on PPC.
- bc2a050d4097 9.2.0 cited
-
Use LWSYNC in place of SYNC/ISYNC in PPC spinlocks, where possible.
- 631beeac3598 9.2.0 cited
-
Use mutex hint bit in PPC LWARX instructions, where possible.
- 5cfa8dd3007d 9.2.0 cited
-
Adjust TAS assembly as per recent discussions: use "+m"(*lock) everywhere
- 109867748259 8.0.0 cited
-
Apple's assembler likes the inlined TAS syntax too, so no reason to
- f9ba0a7fe563 7.4.1 cited
-
Tighten up register usage for inline PPC version of tas().
- eb5e4c58d137 7.4.1 cited
-
Put the isync where it's supposed to be.
- cd35d601b859 7.4.1 cited
-
> > I'll re-check that with the ppc architecture guy here.
- ceb4f5ea9c2c 7.4.1 cited
-
Fix PPC s_lock operations to work correctly on multi-CPU machines.
- 7233aae50bea 7.3.1 cited
-
I tried to build PostgreSQL with the following step to see backends hung
- 50938576d482 7.3.1 cited
-
Complete merge of all old man page information.
- f2f43efbe1d5 7.1.1 cited
-
s_lock aix patch.
- e3b06a871b63 7.1.1 cited
On Thu, Apr 25, 2024 at 01:06:24PM +0900, Michael Paquier wrote: > Anyway, getting an access to such compilers to be able to debug issues > on hosts that take less than 12h to just compile the code would > certainly help its adoption. So seeing commitment in the form of > patches and access to environments would help a lot. Overall, > studying that afresh with v18 looks like a good idea, assuming that > anybody who commits such patches has access to hosts to evaluate them, > with buildfarm members running on top, of course. Agreed. They can't even have buildfarm member for PG 17 since it doesn't compile anymore, so someone has to go over the reverted patch, figure out which ones are still valid, and report back. Trying to add a port, with possible breakage, during beta seems too risky compared to the value. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.