Re: removing old ports and architectures

On Wed, Oct 16, 2013 at 1:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-10-16 13:04:23 -0400, Robert Haas wrote:
>> So I vote for removing IRIX and Tru64 immediately, but I'm a little
>> more hesitant about shooting UnixWare, since it's technically still
>> supported.
>
> I think if somebody wants to have it supported they need to provide a
> buildfarm member and probably a bit of help. Doing any change in this
> area for a platform that nobody has access to in any way seems
> pointless because it will be broken anyway.

I don't agree with that policy. Sure, 97% of our users are probably
running Linux, Windows, MacOS X, or one of the fairly-popular BSD
variants. But I think a part of the appeal of PostgreSQL is that it is
cross-platform, and doesn't require a lot of special hardware support,
and I'm loathe to give that up. It's one thing to say, gee, we don't
know whether this is actually going to compile and work on your
platform, because it's not tested. It's quite something else to say,
anything that's not on this short list of supported platforms has zero
chance of working without jumping through major hoops.

Commit b8ed4cc9627de437e5eafdb81631a0d0f063abb3, from April of this
year, updated our support for --disable-spinlocks. Spinlocks are a
far more basic facility than the sorts of advanced primitives we're
talking about requiring here. If we're going to support compiling
under --disable-spinlocks, then we certainly can't rely on this more
advanced stuff always being present. Even if we get rid of that, it's
throwing up one more barrier in front of people who want to get
PostgreSQL running on a non-mainstream architecture. I've spent
enough time over the years working on odd hardware to have sympathy
for people who want to compile stuff there and have it work, or at
least work after some non-huge amount of hacking.

>> I don't think we can desupport it just because it doesn't have CAS.
>> CAS is very useful and I think we should start using it, but I think
>> we should anticipate a --disable-cas or --disable-atomics option and
>> regularly test that our code works without it. IOW, we can rely on it
>> as an optimization, but not for correctness. Eventually, we can
>> probably desupport all platforms that don't have CAS, but I see that
>> as something that's probably 5 or 10 years away, not something we can
>> do tomorrow.
>
> I think that will result in loads of barely tested duplicative code. If
> there were any even remotely popular platforms requiring this, ok. But
> unless I miss something there really isn't.
>
> We're talking about CPUs with mostly less than 100MHZ here, mostly with
> directly soldered RAM in the one digit MB range. I really don't think
> there's a usecase for running PG on them. And I doubt it still works on
> many of the architectures we advocate.

If stuff is completely ancient and obsolete, I think it's fine to kill
it; it probably doesn't work anyway, and nobody's likely to try. But
I think a lot of the stuff you're talking about is not in that
category.

>> I'm also not sure that this is dead enough to kill.
>>
>> > - M32R (no userspace CAS afaics)
>>
>> Support was added for this in 8.3 and it doesn't seem to be particularly dead.
>
> It's not? All I've read seems to point into a different direction.
>
> The newest supported CPU seems to be
> http://www.renesas.com/products/mpumcu/m32r/m32r_ecu/32196/index.jsp
> sporting a whopping 1024Kb of programmable RAM and only single precision
> FPU.

Well, so, they're an embedded chip. Yes, it's low spec. But then
why'd somebody bother adding spinlock support for it in 2007? It's
not as if that was a high-end chip *then* either.

It's hard to say where to draw the line here. I don't want the
illusion of support for platforms that don't in fact have a prayer of
working to prevent us from making needed improvements. On the other
hand, I also don't want to blithely rip out support for architectures
that people may well still be using and where, in some cases, people
have gone out of their way to add that support. If we get to the
point where some relatively-obscure architecture is the only thing
standing between us and improvement X, then we can weigh those things
against each other and decide. But I don't really want to go rip out
support for half-a-dozen semi-supported architectures without some
clear goal in mind. That just doesn't seem friendly.

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