Re: removing old ports and architectures

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 think we should remove support for the following architectures:
> > - VAX
>
> According to http://en.wikipedia.org/wiki/VAX#History, all
> manufacturing of VAX computers ceased in 2005, but according to
> http://en.wikipedia.org/wiki/OpenVMS#Major_release_timeline, OpenVMS
> is still releasing new versions. I'm not sure what to make of that.

And the last revisions are from 2000 even. I don't think anybody will
actually run a new postgres installation on it.
I also doubt our current version actually compiles there.

> > - superH
>
> Support for spinlocks on SuperH was only recently added, in 9.0. I
> don't think we can assume that no one cares any more.

Yes, I since revised my opinion somewhere downthread. It's pretty much
linux and gcc only, so it's really not that problematic.

Note that our current implementation is broken on many older SuperH (<
SH4) CPUs since their tas isn't safe...

> > - m86k (doesn't have a useable CAS on later iterations like coldfire)

> 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.

> 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.

> > - mips for anything but gcc > 4.4, using gcc's atomics support
> > - s390 for anything but gcc > 4.4, using gcc's atomics support
>
> I'm not clearly how broadly this would sweep, but MIPS doesn't appear dead.

Downthread I noticed it's gcc 4.2 not 4.4. There's some API change in
gcc's atomics support in 4.4 which is why I thought of 4.4 but it
shouldn't affect us after looking in more detail.
Mips seems to only be used with gcc these days, so I think that's ok.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services