Andres Freund <andres@2ndquadrant.com> writes:
> That's a fair point. But all of them will use gcc, right? I've
> previously thought we'd need 4.4 because there's an incompatibility
> between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> atomics for mips seems fine. Given there's no buildfarm animal and
> there's lots of variety out there that seems like a fair amount of
> support.
FWIW, I wouldn't have the slightest bit of difficulty with setting a
project policy that if you want some platform to be supported, you
must provide a buildfarm animal running on it.
More to the point for this specific case, it seems like our process
ought to be
(1) select a preferably-small set of gcc atomic intrinsics that we
want to use.
(2) provide macro wrappers for these so that substituting other
implementations isn't too tough.
(3) for any platform where people don't want to use recent gcc,
insist they provide substitute implementations of the macros.
I don't think the core project has to be responsible for implementing
(3), except maybe on very-mainstream arches such as x86. We can
adopt a self-help attitude for everything else.
But ... having said all that, it would be nice to see some proof of
significant performance benefits that we're going to get from kicking
those non-mainstream arches to the curb. I'm not enamored of removing
real functionality now for vague promises of benefits later.
regards, tom lane
