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: Noah Misch <noah@leadboat.com>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-10-21T02:06:55Z
Lists: pgsql-hackers 
Noah Misch <noah@leadboat.com> writes:
> If the next thing is a patch removing half of the fallback atomics, that is a
> solid reason to remove hppa.

Agreed, though I don't think we have a clear proposal as to what
else to remove.

> The code removed in the last proposed patch was
> not that and was code that never changes, hence my reaction.

Mmm ... I'd agree that the relevant stanzas of s_lock.h/.c haven't
changed in a long time, but port/atomics/ is of considerably newer
vintage and is still receiving a fair amount of churn.  Moreover,
much of what I proposed to remove from there is HPPA-only code with
exactly no parallel in other arches (specifically, the bits in
atomics/fallback.h).  So I don't feel comfortable that it will
continue to work without benefit of testing.  We're taking a risk
just hoping that it will continue to work in the back branches until
they hit EOL.  Expecting that it'll continue to work going forward,
sans testing, seems like the height of folly.

			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.