On 2018-02-27 13:43:23 -0500, Tom Lane wrote:
> Andres Freund <andres@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