| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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 17:49:10 |
| Message-ID: | 20180227174910.3kpcrburdg6l5b3c@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-02-27 10:36:01 -0500, Robert Haas wrote:
> On Tue, Feb 27, 2018 at 8:49 AM, Aleksander Alekseev
> We tried to follow commit messages [1] and discussions [2]. However no matter
> how you try to look on this code it's weird.
I don't see how that makes the code weird. Not fit for your purpose,
sure, but weird?
> > We would like to know whether you share this concern and whether it
> > would be a good idea to try to refactor the code so that atomics could
> > be used not only from the backend.
>
> I think the concern on the referenced threads was that atomics might
> be implemented using spinlocks if we don't have a real atomics
> implementation; and those in turn might be implemented as semaphores
> if we don't have a real spinlock implementation. When we emulate
> atomics using spinlocks, we use a fixed-size array of spinlocks stored
> in shared memory; and when we emulate spinlocks using semaphore, we
> use the semaphores in each PGPROC. So those emulation layers are
> deeply tied into the backend's shared-memory architecture, and
> untangling them might be a bit complicated.
Right.
> 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 ;)
> If #include "atomics.h" worked from all frontend code except where one
> of those emulation layers were in use, that would represent an
> improvement over the current status quo for people doing out-of-core
> development against PostgreSQL.
I think if we wanted to enable this code to be used from frontend, we'd
have to to implement the various fallbacks paths in a bit different way,
so they can be supplied by frontend code. And then we can rely on it on
frontend code for real, if we want to.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2018-02-27 17:53:06 | Re: [HACKERS] MERGE SQL Statement for PG11 |
| Previous Message | Alexander Korotkov | 2018-02-27 17:00:23 | Re: [HACKERS] GUC for cleanup indexes threshold. |