Обсуждение: Remove last traces of HPPA support
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?
regards, tom lane
diff --git a/contrib/pgcrypto/crypt-blowfish.c b/contrib/pgcrypto/crypt-blowfish.c
index 1264eccb3f..5a1b1e1009 100644
--- a/contrib/pgcrypto/crypt-blowfish.c
+++ b/contrib/pgcrypto/crypt-blowfish.c
@@ -41,7 +41,7 @@
#ifdef __i386__
#define BF_ASM 0 /* 1 */
#define BF_SCALE 1
-#elif defined(__x86_64__) || defined(__hppa__)
+#elif defined(__x86_64__)
#define BF_ASM 0
#define BF_SCALE 1
#else
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index f4b1f81189..3608aec595 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -3359,8 +3359,8 @@ export MANPATH
<para>
In general, <productname>PostgreSQL</productname> can be expected to work on
- these CPU architectures: x86, PowerPC, S/390, SPARC, ARM, MIPS, RISC-V,
- and PA-RISC, including
+ these CPU architectures: x86, PowerPC, S/390, SPARC, ARM, MIPS,
+ and RISC-V, including
big-endian, little-endian, 32-bit, and 64-bit variants where applicable.
It is often
possible to build on an unsupported CPU type by configuring with
@@ -3391,7 +3391,8 @@ export MANPATH
<para>
Historical versions of <productname>PostgreSQL</productname> or POSTGRES
also ran on CPU architectures including Alpha, Itanium, M32R, M68K,
- M88K, NS32K, SuperH, and VAX, and operating systems including 4.3BSD, BEOS,
+ M88K, NS32K, PA-RISC, SuperH, and VAX,
+ and operating systems including 4.3BSD, BEOS,
BSD/OS, DG/UX, Dynix, HP-UX, IRIX, NeXTSTEP, QNX, SCO, SINIX, Sprite, SunOS,
Tru64 UNIX, and ULTRIX.
</para>
diff --git a/src/backend/storage/lmgr/s_lock.c b/src/backend/storage/lmgr/s_lock.c
index 327ac64f7c..0e3f04207c 100644
--- a/src/backend/storage/lmgr/s_lock.c
+++ b/src/backend/storage/lmgr/s_lock.c
@@ -110,12 +110,7 @@ s_lock(volatile slock_t *lock, const char *file, int line, const char *func)
void
s_unlock(volatile slock_t *lock)
{
-#ifdef TAS_ACTIVE_WORD
- /* HP's PA-RISC */
- *TAS_ACTIVE_WORD(lock) = -1;
-#else
*lock = 0;
-#endif
}
#endif
diff --git a/src/include/port/atomics.h b/src/include/port/atomics.h
index bbff945eba..f6f62d68c0 100644
--- a/src/include/port/atomics.h
+++ b/src/include/port/atomics.h
@@ -69,8 +69,6 @@
#include "port/atomics/arch-x86.h"
#elif defined(__ppc__) || defined(__powerpc__) || defined(__ppc64__) || defined(__powerpc64__)
#include "port/atomics/arch-ppc.h"
-#elif defined(__hppa) || defined(__hppa__)
-#include "port/atomics/arch-hppa.h"
#endif
/*
diff --git a/src/include/port/atomics/arch-hppa.h b/src/include/port/atomics/arch-hppa.h
deleted file mode 100644
index 4c89fbff71..0000000000
--- a/src/include/port/atomics/arch-hppa.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*-------------------------------------------------------------------------
- *
- * arch-hppa.h
- * Atomic operations considerations specific to HPPA
- *
- * Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
- * Portions Copyright (c) 1994, Regents of the University of California
- *
- * NOTES:
- *
- * src/include/port/atomics/arch-hppa.h
- *
- *-------------------------------------------------------------------------
- */
-
-/* HPPA doesn't do either read or write reordering */
-#define pg_memory_barrier_impl() pg_compiler_barrier_impl()
diff --git a/src/include/port/atomics/fallback.h b/src/include/port/atomics/fallback.h
index a9e8e77c03..d119e8cc50 100644
--- a/src/include/port/atomics/fallback.h
+++ b/src/include/port/atomics/fallback.h
@@ -75,11 +75,7 @@ typedef struct pg_atomic_flag
* be content with just one byte instead of 4, but that's not too much
* waste.
*/
-#if defined(__hppa) || defined(__hppa__) /* HP PA-RISC, GCC and HP compilers */
- int sema[4];
-#else
int sema;
-#endif
volatile bool value;
} pg_atomic_flag;
@@ -93,11 +89,7 @@ typedef struct pg_atomic_flag
typedef struct pg_atomic_uint32
{
/* Check pg_atomic_flag's definition above for an explanation */
-#if defined(__hppa) || defined(__hppa__) /* HP PA-RISC */
- int sema[4];
-#else
int sema;
-#endif
volatile uint32 value;
} pg_atomic_uint32;
@@ -111,11 +103,7 @@ typedef struct pg_atomic_uint32
typedef struct pg_atomic_uint64
{
/* Check pg_atomic_flag's definition above for an explanation */
-#if defined(__hppa) || defined(__hppa__) /* HP PA-RISC */
- int sema[4];
-#else
int sema;
-#endif
volatile uint64 value;
} pg_atomic_uint64;
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index c9fa84cc43..e76e8b6888 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -530,71 +530,6 @@ do \
#endif /* __mips__ && !__sgi */
-#if defined(__hppa) || defined(__hppa__) /* HP PA-RISC */
-/*
- * HP's PA-RISC
- *
- * Because LDCWX requires a 16-byte-aligned address, we declare slock_t as a
- * 16-byte struct. The active word in the struct is whichever has the aligned
- * address; the other three words just sit at -1.
- */
-#define HAS_TEST_AND_SET
-
-typedef struct
-{
- int sema[4];
-} slock_t;
-
-#define TAS_ACTIVE_WORD(lock) ((volatile int *) (((uintptr_t) (lock) + 15) & ~15))
-
-static __inline__ int
-tas(volatile slock_t *lock)
-{
- volatile int *lockword = TAS_ACTIVE_WORD(lock);
- int lockval;
-
- /*
- * The LDCWX instruction atomically clears the target word and
- * returns the previous value. Hence, if the instruction returns
- * 0, someone else has already acquired the lock before we tested
- * it (i.e., we have failed).
- *
- * Notice that this means that we actually clear the word to set
- * the lock and set the word to clear the lock. This is the
- * opposite behavior from the SPARC LDSTUB instruction. For some
- * reason everything that H-P does is rather baroque...
- *
- * For details about the LDCWX instruction, see the "Precision
- * Architecture and Instruction Reference Manual" (09740-90014 of June
- * 1987), p. 5-38.
- */
- __asm__ __volatile__(
- " ldcwx 0(0,%2),%0 \n"
-: "=r"(lockval), "+m"(*lockword)
-: "r"(lockword)
-: "memory");
- return (lockval == 0);
-}
-
-#define S_UNLOCK(lock) \
- do { \
- __asm__ __volatile__("" : : : "memory"); \
- *TAS_ACTIVE_WORD(lock) = -1; \
- } while (0)
-
-#define S_INIT_LOCK(lock) \
- do { \
- volatile slock_t *lock_ = (lock); \
- lock_->sema[0] = -1; \
- lock_->sema[1] = -1; \
- lock_->sema[2] = -1; \
- lock_->sema[3] = -1; \
- } while (0)
-
-#define S_LOCK_FREE(lock) (*TAS_ACTIVE_WORD(lock) != 0)
-
-#endif /* __hppa || __hppa__ */
-
/*
* If we have no platform-specific knowledge, but we found that the compiler
diff --git a/src/tools/pginclude/cpluspluscheck b/src/tools/pginclude/cpluspluscheck
index 4e09c4686b..96852ef75f 100755
--- a/src/tools/pginclude/cpluspluscheck
+++ b/src/tools/pginclude/cpluspluscheck
@@ -84,12 +84,10 @@ do
# Likewise, these files are platform-specific, and the one
# relevant to our platform will be included by atomics.h.
test "$f" = src/include/port/atomics/arch-arm.h && continue
- test "$f" = src/include/port/atomics/arch-hppa.h && continue
test "$f" = src/include/port/atomics/arch-ppc.h && continue
test "$f" = src/include/port/atomics/arch-x86.h && continue
test "$f" = src/include/port/atomics/fallback.h && continue
test "$f" = src/include/port/atomics/generic.h && continue
- test "$f" = src/include/port/atomics/generic-acc.h && continue
test "$f" = src/include/port/atomics/generic-gcc.h && continue
test "$f" = src/include/port/atomics/generic-msvc.h && continue
test "$f" = src/include/port/atomics/generic-sunpro.h && continue
diff --git a/src/tools/pginclude/headerscheck b/src/tools/pginclude/headerscheck
index 8dee1b5670..0b9b9740f4 100755
--- a/src/tools/pginclude/headerscheck
+++ b/src/tools/pginclude/headerscheck
@@ -79,12 +79,10 @@ do
# Likewise, these files are platform-specific, and the one
# relevant to our platform will be included by atomics.h.
test "$f" = src/include/port/atomics/arch-arm.h && continue
- test "$f" = src/include/port/atomics/arch-hppa.h && continue
test "$f" = src/include/port/atomics/arch-ppc.h && continue
test "$f" = src/include/port/atomics/arch-x86.h && continue
test "$f" = src/include/port/atomics/fallback.h && continue
test "$f" = src/include/port/atomics/generic.h && continue
- test "$f" = src/include/port/atomics/generic-acc.h && continue
test "$f" = src/include/port/atomics/generic-gcc.h && continue
test "$f" = src/include/port/atomics/generic-msvc.h && continue
test "$f" = src/include/port/atomics/generic-sunpro.h && continue
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: https://www.postgresql.org/message-id/flat/959917.1657522169%40sss.pgh.pa.us#47f7af4817dc8dc0d8901d1ee965971e 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: https://www.postgresql.org/message-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A%40BYAPR02MB4262.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: > >https://www.postgresql.org/message-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A%40BYAPR02MB4262.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: >> https://www.postgresql.org/message-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A%40BYAPR02MB4262.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: > > https://www.postgresql.org/message-id/BYAPR02MB42624ED41C15BFA82DAE2C359BD5A%40BYAPR02MB4262.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.