Re: AIX support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Srirama Kucherlapati <sriram(dot)rk(at)in(dot)ibm(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com>, Aditya Kamath <Aditya(dot)Kamath1(at)ibm(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "peter(at)eisentraut(dot)org" <peter(at)eisentraut(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "tristan(at)partin(dot)io" <tristan(at)partin(dot)io>, "postgres-ibm-aix(at)wwpdl(dot)vnet(dot)ibm(dot)com" <postgres-ibm-aix(at)wwpdl(dot)vnet(dot)ibm(dot)com>
Subject: Re: AIX support
Date: 2026-02-02 02:18:08
Message-ID: 399291.1769998688@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> * s_lock.h changes: it's not okay to change anything affecting non-AIX
> I've done a little research on this topic, which I'll include in a
> separate message.

So, as previously mentioned, the problem with what the v11 patch
does in s_lock.h is that it changes the implementation of spinlocks
for every PPC platform not only AIX. We would accept that given
proof that __sync_lock_test_and_set() is as good or better than the
existing hand-rolled assembler on every PPC platform. But you've
offered no such proof and it seems like sufficient evidence would be
pretty hard to come by. I think you're far better off not changing
this code for non-AIX in the initial commit. We can always revisit
the topic later at leisure.

There are a couple of ways you could do that. An easy answer is
some #ifdefs:

static __inline__ int
tas(volatile slock_t *lock)
{
+#ifndef _AIX
slock_t _t;
int _res;
...
: "memory", "cc");
return _res;
+#else
+ return __sync_lock_test_and_set(lock, 1);
+endif
}

However, I wonder whether you've even proven that
__sync_lock_test_and_set is a win on AIX. On the same principle
of "get it working again first and optimize later", it might be
better to resurrect the longstanding asm implementation and then
later look into whether the compiler intrinsic improves matters.

One way to do that is to undo what Heikki did in 0b16bb877, and
put back the hard-wired branch offsets I introduced in c41a1215f.
But I totally sympathize with Heikki's edits: those hard-wired
offsets were hard to read and harder to maintain. Googling led
me to another answer: we can use gcc's "%=" insn counter to
generate normal assembler labels that are distinct across
multiple uses of TAS(). I don't know why we didn't choose
this approach in 2015, other than that I didn't know of that
feature personally. Some archaeology shows that gcc has had
"%=" since gcc 2.0, so it's hardly too new.

Hence, I suggest the attached alternative solution, at least for
the first pass at this. I've checked that this works on both AIX
(cfarm119) and NetBSD/ppc (mamba's host).

regards, tom lane

Attachment Content-Type Size
alternative-ppc-tas-code.patch text/x-diff 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-02-02 02:26:28 Re: relkind as an enum
Previous Message Xuneng Zhou 2026-02-02 02:16:56 Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery