On 2018-02-27 13:43:23 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2018-02-27 10:36:01 -0500, Robert Haas wrote: > >> However, those are presumably rare configurations that many people > >> (including many developers) don't care about. > > > I don't think that's quite true anymore. We e.g. now rely on 64bit > > atomics being emulated on some machines, and they're unavailable on a > > bigger number of systems than atomics proper, particularly 32bit > > sytems. There's also hppa, of course ;) > > I had the idea that there were also still some MIPS machines out there > with no real atomics support. If there's not, I wouldn't complain > hard about deciding to desupport HPPA, whenever we want to rip out > the fallbacks.
There's definitely several machines that we currently support without good enough atomics support. I don't *think* mips is among them, the architectural manuals I had looked at when implementing it suggested ll/sc type support is available everywhere. https://wiki.postgresql.org/wiki/Atomics lacking 32 bit atomics: armv5, sparcv8, pa-risc, m32r, i386 lacking 64 bit atomics: some ppc, armv6, i486, !gcc !msvc x86 in 32bit mode None of these seem extremely interesting personally, but I'm way happier to drop platforms than some others ; > I am not sure though that we want to promise that atomics.h would work > in arbitrary frontend environments in any case. Those functions are > very specifically intended to do what PG needs them to do; do we > really want them to try to serve multiple masters? I think if we'd allow the client to implement a locking mechanism for the fallback implementation, there'd not be a big issue. Besides the fallback code there's really not that much PG specificity in there... Greetings, Andres Freund
