On Sat, Oct 12, 2013 at 8:46 PM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
