Re: Remove last traces of HPPA support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove last traces of HPPA support
Date
Msg-id 3994077.1697838419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove last traces of HPPA support  (Andres Freund <andres@anarazel.de>)
Responses Re: Remove last traces of HPPA support
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
>> Hmm, are you saying there's more of port/atomics/ that could be
>> removed?  What exactly?

> I was thinking we could remove the whole fallback path for atomic operations,
> but it's a bit less, because we likely don't want to mandate support for 64bit
> atomics yet.

Yeah.  That'd be tantamount to desupporting 32-bit arches altogether,
I think.  I'm not ready to go there yet.

> That'd still allow removing more than half of
> src/include/port/atomics/fallback.h and src/backend/port/atomics.c - and more
> if we finally decided to require a spinlock implementation.

In the wake of 1c72d82c2, it seems likely that requiring some kind of
spinlock implementation is not such a big lift.  Certainly, a machine
without that hasn't been a fit target for production in a very long
time, so maybe we should just drop that semaphore-based emulation.

>> Do we really want to assume that all future architectures will have atomic
>> operations?

> Yes. Outside of the tiny microcontrollers, which obviously won't run postgres,
> I cannot see any future architecture not having support for atomic operations.

I'd like to refine what that means a bit more.  Are we assuming that
a machine providing any of the gcc atomic intrinsics (of a given
width) will provide all of them?  Or is there a specific subset that
we can emulate the rest on top of?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Remove last traces of HPPA support
Next
From: Thomas Munro
Date:
Subject: Re: LLVM 16 (opaque pointers)