Re: Remove last traces of HPPA support

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Remove last traces of HPPA support
Date: 2023-10-21 05:56:31
Message-ID: 20231021055631.gx6ugq3fn6k6nc76@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-10-20 22:06:55 -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)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.

It'd be one thing to continue supporting an almost-guaranteed-to-be-unused
platform, if we expected it to become more popular or complete enough to be
usable like e.g. risc-v a few years ago. But I doubt we'll find anybody out
there believing that there's a potential future upward trend for HPPA.

IMO a single person looking at HPPA code for a few minutes is a cost that more
than outweighs the potential benefits of continuing "supporting" this dead
arch. Even code that doesn't need to change has costs, particularly if it's
intermingled with actually important code (which spinlocks certainly are).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-10-21 06:08:05 Re: LLVM 16 (opaque pointers)
Previous Message Tom Lane 2023-10-21 05:27:58 Re: Add support for AT LOCAL