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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers