Re: Remove last traces of HPPA support

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-10-20T21:33:23Z
Lists: pgsql-hackers
Hi,

On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > In addition to the point Tom has made, I think it's also not correct that hppa
> > doesn't impose a burden: hppa is the only of our architectures that doesn't
> > actually support atomic operations, requiring us to have infrastructure to
> > backfill atomics using spinlocks. This does preclude some uses of atomics,
> > e.g. in signal handlers - I think Thomas wanted to do so for some concurrency
> > primitive.
> 
> 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. 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.


> 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.

Greetings,

Andres Freund



Commits

  1. Require memory barrier support.

  2. Require compiler barrier support.

  3. Remove --disable-atomics, require 32 bit atomics.

  4. Remove --disable-spinlocks.

  5. Remove support for HPPA (a/k/a PA-RISC) architecture.

  6. Add a basic atomic ops API abstracting away platform/architecture details.