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

From Noah Misch
Subject Re: Remove last traces of HPPA support
Date
Msg-id 20231021014225.11@rfd.leadboat.com
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
On Fri, Oct 20, 2023 at 12:40:00PM -0700, Andres Freund wrote:
> On 2023-10-19 17:23:04 -0700, Noah Misch wrote:
> > On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:
> > > We removed support for the HP-UX OS in v16, but left in support
> > > for the PA-RISC architecture, mainly because I thought that its
> > > spinlock mechanism is weird enough to be a good stress test
> > > for our spinlock infrastructure.  It still is that, but my
> > > one remaining HPPA machine has gone to the great recycle heap
> > > in the sky.  There seems little point in keeping around nominal
> > > support for an architecture that we can't test and no one is
> > > using anymore.
> > > 
> > > Hence, the attached removes the remaining support for HPPA.
> > > Any objections?
> > 
> > I wouldn't do this.  NetBSD/hppa still claims to exist, as does the OpenBSD
> > equivalent.  I presume its pkgsrc compiles this code.  The code is basically
> > zero-maintenance, so there's not much to gain from deleting it preemptively.
> 
> 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.

If the next thing is a patch removing half of the fallback atomics, that is a
solid reason to remove hppa.  The code removed in the last proposed patch was
not that and was code that never changes, hence my reaction.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: LLVM 16 (opaque pointers)
Next
From: Tom Lane
Date:
Subject: Re: LLVM 16 (opaque pointers)