Horton

Re: Remove last traces of HPPA support

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-10-20T19:59:42Z
Lists: pgsql-hackers 
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?  Do we really want to assume that all
future architectures will have atomic operations?

			regards, tom lane

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.