removing old ports and architectures

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: removing old ports and architectures
Date: 2013-10-13 00:46:58
Message-ID: 20131013004658.GG4056218@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

As discussed in 20130926225545(dot)GB26663(at)awork2(dot)anarazel(dot)de and on quite
some other occasions there's quite some scalability improvements we
could make if we had cross platform support for atomic
operations. Providing that is a fair bit of work for every
architecture/compiler/OS, so I think it's a reasonable thing to remove
unused things first.
Alternatively we can maintain parallel code paths for atomic ops
supporting platforms and for those without, but that seems like a bad
idea from a complexity and testing perspective given that all even
remotely current platforms should support them.

I think we should remove support the following ports:
- IRIX
- UnixWare
- Tru64

Neither of those are relevant.

I think we should remove support for the following architectures:
- VAX
- univel (s_lock support remaining)
- sinix (s_lock support remaining)
- sun3 (I think it's just s_lock support remaining)
- natsemi 32k
- superH
- ALPHA (big pain in the ass to get right, nobody uses it anymore)
- m86k (doesn't have a useable CAS on later iterations like coldfire)
- M32R (no userspace CAS afaics)
- mips for anything but gcc > 4.4, using gcc's atomics support
- s390 for anything but gcc > 4.4, using gcc's atomics support
- 32bit/<v9 sparc (doesn't have proper atomics, old)

Possibly:
- all mips
- PA-RISC. I think Tom was the remaining user there? Maybe just !gcc.

Any arguments against?

Last round of discussion of removing dead ports:
1335292179(dot)13481(dot)4(dot)camel(at)vanquo(dot)pezone(dot)net

Discusses state of of spinlocks and barriers on various platforms:
20130920151110(dot)GA8508(at)awork2(dot)anarazel(dot)de

Greetings,

Andres Freund

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2013-10-13 01:01:14 Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Previous Message Kohei KaiGai 2013-10-12 20:53:06 Re: background workers, round three