Remove last traces of HPPA support

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.

Looks OK for the C parts.

Hence, the attached removes the remaining support for HPPA.
Any objections?

Would a refresh of config/config.guess and config/config.sub be
suited? This stuff still has references to HPPA.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:

Hence, the attached removes the remaining support for HPPA.
Any objections?

Would a refresh of config/config.guess and config/config.sub be
suited? This stuff still has references to HPPA.

AFAIK we just absorb those files verbatim from upstream. There is plenty
of stuff in them for systems we don't support; it's not worth trying
to clean that out.

regards, tom lane

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.

Noah Misch <noah@leadboat.com> writes:

On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:

Hence, the attached removes the remaining support for HPPA.

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.

I doubt it: I don't think anyone is routinely building very much of
pkgsrc for backwater hardware like HPPA, on either distro. It takes
too much time (as cross-build doesn't work IME) and there are too few
potential users. I certainly had to build all my own packages during
my experiments with running those systems on my machine.

Moreover, if they are compiling it they aren't testing it.
I filed a pile of bugs against NetBSD kernel and toolchains
on the way to getting the late lamented chickadee animal running.
While it was pretty much working when I retired chickadee, it was
obviously ground that nobody else had trodden in a long time.

As for OpenBSD, while I did have a working installation of 6.4
at one time, I completely failed to get 7.1 running on that
hardware. I think it's maintained only for very small values
of "maintained".

Lastly, even when they're working those systems are about half
the speed of HP-UX on the same hardware; and even when using HP-UX
there is no HPPA hardware that's not insanely slow by modern
standards. I can't believe that anyone would want to run modern
PG on that stack, and I don't believe that anyone but me has
tried in a long time.

regards, tom lane

On Fri, Oct 20, 2023 at 4:21 AM Tom Lane <tgl@sss.pgh.pa.us> 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.

+1

I wrote:

Noah Misch <noah@leadboat.com> writes:

On Thu, Oct 19, 2023 at 11:16:28AM -0400, Tom Lane wrote:

Hence, the attached removes the remaining support for HPPA.

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.

I doubt it: I don't think anyone is routinely building very much of
pkgsrc for backwater hardware like HPPA, on either distro.

I dug a bit further on this point. The previous discussion about
our policy for old-hardware support was here:

/messages/by-id/959917.1657522169@sss.pgh.pa.us

The existence of a NetBSD/sh3el package for Postgres didn't stop
us from dropping SuperH support. Moreover, the page showing the
existence of that package:

https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/databases/postgresql14-server/index.html

also shows a build for VAX, which we know positively would not
have passed regression tests, so they certainly weren't testing
those builds. (And, to the point here, it does *not* show any
build for hppa.)

The bottom line, though, is that IMV we agreed in that thread to a
policy that no architecture will be considered supported unless
it has a representative in the buildfarm. We've since enforced
that policy in the case of loongarch64, so it seems established.
With my HPPA animal gone, and nobody very likely to step up with
a replacement, HPPA no longer meets that threshold requirement.

regards, tom lane

Hi,

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.

Greetings,

Andres Freund

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

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

Andres Freund <andres@anarazel.de> writes:

On 2023-10-20 15:59:42 -0400, Tom Lane wrote:

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.

Yeah. That'd be tantamount to desupporting 32-bit arches altogether,
I think. I'm not ready to go there 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.

In the wake of 1c72d82c2, it seems likely that requiring some kind of
spinlock implementation is not such a big lift. Certainly, a machine
without that hasn't been a fit target for production in a very long
time, so maybe we should just drop that semaphore-based emulation.

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.

I'd like to refine what that means a bit more. Are we assuming that
a machine providing any of the gcc atomic intrinsics (of a given
width) will provide all of them? Or is there a specific subset that
we can emulate the rest on top of?

regards, tom lane

Hi,

On 2023-10-20 17:46:59 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2023-10-20 15:59:42 -0400, Tom Lane wrote:

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.

Yeah. That'd be tantamount to desupporting 32-bit arches altogether,
I think. I'm not ready to go there yet.

It shouldn't be tantamount to that - many 32bit archs support 64bit atomic
operations. E.g. x86 supported it since the 586 (in 1993). However, arm only
addded them to 32 bit, in an extension, comparatively recently...

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.

In the wake of 1c72d82c2, it seems likely that requiring some kind of
spinlock implementation is not such a big lift. Certainly, a machine
without that hasn't been a fit target for production in a very long
time, so maybe we should just drop that semaphore-based emulation.

Yep. And the performance drop due to not having spinlock is also getting worse
over time, with CPU bound workloads having become a lot more common due to
larger amounts of memory and much much faster IO.

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.

I'd like to refine what that means a bit more. Are we assuming that a
machine providing any of the gcc atomic intrinsics (of a given width) will
provide all of them? Or is there a specific subset that we can emulate the
rest on top of?

Right now we don't require that. As long as we know how to do atomic compare
exchange, we backfill all other atomic operations using compare-exchange -
albeit less efficiently (there's no retries for atomic-add when implemented
directly, but there are retries when using cmpxchg, the difference can be
significant under contention).

Practically speaking I think it's quite unlikely that a compiler + arch
combination will have only some intrinsics of some width - I think all
compilers have infrastructure to fall back to compare-exchange when there's no
dedicated atomic operation for some intrinsic.

Greetings,

Andres Freund

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.

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

Hi,

On 2023-10-20 22:06:55 -0400, Tom Lane wrote:

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.

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

Andres Freund <andres@anarazel.de> writes:

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.

Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
until I noticed this message a few days ago:

/messages/by-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A@BYAPR02MB4262.namprd02.prod.outlook.com

But we already cut that user off at the knees by removing HP-UX support.

The remaining argument for worrying about this architecture being in
use in the field is the idea that somebody is using it on top of
NetBSD or OpenBSD. But having used both of those systems (or tried
to), I feel absolutely confident in asserting that nobody is using
it in production today, let alone hoping to continue using it.

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).

Yup, that. It's not zero cost to carry this stuff.

regards, tom lane

Hi,

On October 20, 2023 11:18:19 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> writes:

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.

Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
until I noticed this message a few days ago:

/messages/by-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A@BYAPR02MB4262.namprd02.prod.outlook.com

But we already cut that user off at the knees by removing HP-UX support.

Not that it matters really, but I'd assume that was hpux on ia64, not hppa?

Greetings,

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Andres Freund <andres@anarazel.de> writes:

On October 20, 2023 11:18:19 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
until I noticed this message a few days ago:
/messages/by-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A@BYAPR02MB4262.namprd02.prod.outlook.com
But we already cut that user off at the knees by removing HP-UX support.

Not that it matters really, but I'd assume that was hpux on ia64, not hppa?

Hmm, maybe ... impossible to tell from the given information, but ia64
was at least still in production till recently, so you might be right.

In any case, I heard no bleating when we nuked ia64 support.

regards, tom lane

On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

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.

Indeed. I would have bet that Postgres on HPPA was extinct in the wild,
until I noticed this message a few days ago:

/messages/by-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A@BYAPR02MB4262.namprd02.prod.outlook.com

But we already cut that user off at the knees by removing HP-UX support.

The remaining argument for worrying about this architecture being in
use in the field is the idea that somebody is using it on top of
NetBSD or OpenBSD. But having used both of those systems (or tried
to), I feel absolutely confident in asserting that nobody is using
it in production today, let alone hoping to continue using it.

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).

Yup, that. It's not zero cost to carry this stuff.

+1 for dropping it.

Noah Misch <noah@leadboat.com> writes:

On Sat, Oct 21, 2023 at 02:18:19AM -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

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).

Yup, that. It's not zero cost to carry this stuff.

+1 for dropping it.

Done at commit edadeb0710.

regards, tom lane