Re: 9.4 broken on alpha

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: 9.4 broken on alpha
Date: 2015-08-30 20:42:53
Message-ID: 31123.1440967373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> At a minimum, we should de-support every platform on which literally
> no new deployments will ever happen.
> I'm looking specifically at you, HPUX, and I could make a pretty good
> case for the idea that we can relegate 32-bit platforms to the ash
> heap of history, at least on the server side.

This wasn't responded to very much, but I wanted to put on record
that I don't agree with the concept. There are several reasons:

1. "Run on every platform you can" is in the DNA of this and just about
every other successful open-source project. You don't want to drive away
potential users by not supporting their platform. If they're still
getting good use out of an old OS or non-mainstream architecture, who are
we to tell them not to?

2. Even if a particular platform is no longer a credible target for
production deployments, it can be a useful test case to ensure that we
don't get frozen into a narrow "FooOS on x86_64 is the only case worth
considering" straitjacket. Software monocultures are bad news; they tend
not to adapt very well when the world changes. So for instance I'm
reluctant to shut down pademelon, even though its compiler is old enough
to vote, because it's one of not too darn many buildfarm animals whose
compilers are not gcc or derivatives. We need cases like that to keep us
from building in gcc-isms. In short, supporting old platforms is one of
the ways that we stay flexible enough to be able to support new platforms
in the future.

3. I see no reason to desupport platforms when we don't gain anything by
it. In the case of Alpha, it's pretty clear what we gain: we don't have
to worry about its unlike-anything-else memory coherency model. (I'm not
very worried that future platforms will adopt that idea, either.) And the
lack of any support from its remaining user community tilts the scales
pretty heavily against it. I'll be happy to drop testing on HPUX 10.20,
or the ancient OS X versions my other buildfarm critters run, the minute
there is some feature we have a clear need for that one of them doesn't
have. But I don't think it's desirable to cut anything off as long as
it's still able to run a buildfarm member. I think those critters are
still capable of catching unexpected portability issues that might affect
more-viable platforms too.

A useful comparison point is the testing Greg Stark did recently for VAX.
Certainly no-one's ever again going to try to get useful work done with
Postgres on a VAX, but that still taught us some good things about
unnecessary IEEE-floating-point dependencies that had snuck into the code.
Someday, that might be important; IEEE 754 won't be the last word on
float arithmetic forever.

As an example of a desupport proposal that I think *is* well-founded,
see my nearby message <27975(dot)1440961181(at)sss(dot)pgh(dot)pa(dot)us>.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-08-30 21:56:58 Re: [patch] Proposal for \rotate in psql
Previous Message Christoph Berg 2015-08-30 20:32:06 Re: datestyle=postgres broken with timezone=UTC+N