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
-
Require memory barrier support.
- 83aadbeb96f0 18.0 landed
-
Require compiler barrier support.
- a011dc399cc8 18.0 landed
-
Remove --disable-atomics, require 32 bit atomics.
- 813852613629 18.0 landed
-
Remove --disable-spinlocks.
- e25626677f80 18.0 landed
-
Remove support for HPPA (a/k/a PA-RISC) architecture.
- edadeb0710e8 18.0 landed
-
Add a basic atomic ops API abstracting away platform/architecture details.
- b64d92f1a560 9.5.0 cited