On 2015-01-10 18:40:58 -0500, Tom Lane wrote: > Andres Freund <and...@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.
Are you sure it actually worked on hppa && !gcc? Sure, the s_lock.h gcc breakage is caused by Robert's s_lock.h commit (making spinlock proper barriers), but I don't see how the tree as of 89779bf2c8f9aa48 could work on !gcc hppa? At least bgworker.c already used read and write barriers back then. Those were redefined to a compiler barrier by /* HPPA doesn't do either read or write reordering */ #define pg_memory_barrier() pg_compiler_barrier() but barrier.h only provided (back then) compiler barriers for icc, gcc, ia64 (without a compiler restriction?) and win32. So I don't see how that could have worked. On a reread, you even noted "But note this patch only fixes things for gcc, not for builds with HP's compiler." in the commit message.. Anyway, i've pushed a fix for that to master. For one I'm not yet sure if it's actually broken in the backbranches (and if we care), for another the <= 9.4 fix will not have a single file in common anyway. Any opinion on that? Could you check whether that heals that problem? I've verified that it allows me to build with gcc, even if I remove its compiler barrier definition. > > 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. And I really doubt any of those that do fail to provide a compiler barrier... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
