Re: removing old ports and architectures

On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> I think we should remove support the following ports:
> - IRIX
> - UnixWare
> - Tru64

According to http://en.wikipedia.org/wiki/IRIX, IRIX has been
officially retired. The last release of IRIX was in 2006 and support
will end in December of 2013. Therefore, it will be unsupported by
the time PostgreSQL 9.4 is released.

According to http://en.wikipedia.org/wiki/UnixWare, UnixWare is not
dead, although there have been no new releases in 5 years.

According to http://en.wikipedia.org/wiki/Tru64_UNIX, Tru64 has been
officially retired. Support ended in December, 2012. This seems safe
to remove.

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.

> Neither of those are relevant.
>
> 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.

> - univel (s_lock support remaining)

We removed the univel port in 9.2 and didn't get any complaints, but
the s_lock support is still used by the SCO and UnixWare ports, except
under GCC.

> - sinix (s_lock support remaining)

This seems to be quite thoroughly dead. The best information I can
find indicates that development ended in 2002 and support in 2008. I
think we can remove this.

> - sun3 (I think it's just s_lock support remaining)
> - natsemi 32k

Both of these are so old I can hardly find any information on them.
Seems clear to nuke these.

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

> - ALPHA (big pain in the ass to get right, nobody uses it anymore)

It seems somehow a shame to let this one go, but I agree it's a big
pain in the ass to get it right.

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

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

> - 32bit/<v9 sparc (doesn't have proper atomics, old)

Seems fine to remove this.

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