Re: Remove last traces of HPPA support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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 06:18:19
Message-ID: 4055644.1697869099@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-10-21 06:22:43 Re: Remove last traces of HPPA support
Previous Message Andres Freund 2023-10-21 06:08:05 Re: LLVM 16 (opaque pointers)