Re: atomics.h may not be included from frontend code

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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.