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