From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: atomics.h may not be included from frontend code |
Date: | 2018-02-27 18:43:23 |
Message-ID: | 12237.1519757003@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-02-27 18:47:45 | Re: [HACKERS] [bug-fix] Cannot select big bytea values (~600MB) |
Previous Message | Andres Freund | 2018-02-27 18:42:19 | Re: Sigh, I broke crake again |