Re: s_lock.h default definitions are rather confused

Andres Freund <andres@2ndquadrant.com> writes:
> On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
>> Ick, that one is my failure.

> Actually. It looks like I only translated the logic from barrier.h 1:1
> and it already was broken there. Hm, it looks like the current code
> essentially is from 89779bf2c8f9aa480e0ceb8883f93e9d65c43a6e.

There's a small difference, which is that the code actually worked as
of that commit.  I suspect this got broken by Robert's barrier-hacking
of a few months ago.  I don't think I've tried the non-gcc build since
committing 89779bf2c8f9aa48 :-(

> Unless somebody protests I'm going to introduce a generic fallback
> compiler barrier that's just a extern function.

Seems reasonable to me.  An empty external function should do the job
for any compiler that isn't doing cross-procedural analysis.
        regards, tom lane