Re: removing old ports and architectures - Mailing list pgsql-hackers

On Wed, Oct 16, 2013 at 10:04:29PM +0200, Andres Freund wrote:
> On 2013-10-16 15:49:54 -0400, Bruce Momjian wrote:
> > On Sat, Oct 12, 2013 at 06:35:00PM -0700, Peter Geoghegan wrote:
> > > > - ALPHA (big pain in the ass to get right, nobody uses it anymore)
> > > 
> > > Yes, for many years now ALPHA has only been useful as a way of
> > > illustrating how bad it's possible for CPU memory operation reordering
> > > considerations to get. So I quite agree.
> > 
> > Are there any optimizations we have avoided, or 'volatile' designations
> > added, only for Alpha?
> 
> I am somewhat sure that some of the code we added in the last years
> isn't actually correct for alpha (and others actually). It's just that
> nobody actually runs on alpha anymore, so nobody notices.
> 
> > Could we improve other things if Alpha support was dropped?
> 
> I think the major thing is that if we're going to add more algorithms
> that use less locks - which we'll have to, otherwise our scalability
> will get more and more problematic - we'll have to adhere to the
> weakest cache coherency model we support. And at least I am not
> intelligent/experienced enough to blindly write correct code for Alpha.

Removing support for alpha is a different animal compared to removing support
for non-gcc MIPS and most of the others in your list.  A hacker wishing to
restore support for another MIPS compiler would fill in the assembly code
blanks, probably using code right out of an architecture manual.  A hacker
wishing to restore support for alpha would find himself auditing every
lock-impoverished algorithm in the backend.  At the same time, as you suggest,
the benefit to general PostgreSQL development from dropping alpha is greater
in the same way.  Dropping non-gcc MIPS reduces effort to complete the initial
patch that adds the atomic primitives; dropping alpha reduces effort to
implement every future algorithm that uses barriers.  I do think dropping
support for alpha is the right decision.  That's a firm and likely one-way
downgrade of support, much like we've done for compilers with no 64-bit type.

Concerning cases like non-gcc MIPS, I'll mostly echo Tom's comments[1].  I'm
comfortable with the project saying "We've added atomics for the architectures
we have.  Help us with the rest!"  It's reasonable to introduce an improvement
that entails architecture-dependent code without requiring that the initial
patch and initial author address every interesting target.  The bar to restore
"support", even years later, will be pretty low.  In that light, I don't favor
ripping out longstanding architecture-specific code for borderline platforms.
Doing so raises the bar for restoring support, without proximate benefit.

[1] http://www.postgresql.org/message-id/4694.1381676172@sss.pgh.pa.us

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com