Re: 9.4 broken on alpha - Mailing list pgsql-hackers

On Sun, Aug 30, 2015 at 4:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Fetter <david@fetter.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.

I agree with all this.

I doubt there is a big problem with supporting Alpha apart from
lock-free algorithms.  If critical sections are protected with locks,
I don't believe Alpha requires any special handling.  However,
lock-free algorithms are important.  Given a choice between continuing
to introduce more of them were as necessary to improve scalability and
performance, and continuing to support Alpha, I doubt anyone here is
prepared to vote for the latter.  Even if Alpha servers were readily
available both in the buildfarm and for developer testing, I suspect
most people here would be skeptical about requiring future lock-free
algorithms to support Alpha.  But since they aren't available,
imposing that requirement isn't even a realistic option.

The best argument for continuing to support Alpha is probably that
Linux does.  I don't know how they do that.  Presumably most Linux
kernel developers don't have access to Alpha hardware, which makes me
wonder how they avoid missing read_barrier_depends() in places where
it is needed (since it's a no-op everywhere else).  Considering that
Linux's use of lock-free algorithms is vastly more extensive than
ours, it would seem awfully difficult to avoid introducing bugs of
that type.

I previously argued that, rather than changing lwlock.c to use atomics
categorically (and falling back to atomics emulation when real atomics
are not available), we should have two implementations, one based on
atomics and the other relying only on spinlocks.  I believe if we'd
done that, we would be in a position to continue supporting Alpha and
whatever other weird stuff comes up in the future, because, again, I
think lock-based algorithms should be solid everywhere.  Once we
didn't take that path, I think the die was cast.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company