Re: s_lock.h default definitions are rather confused

On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
> On 2015-01-10 17:58:10 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > > Given you got the error above, you used gcc. Have you used non-gcc
> > > compiler on hppa recently? I seem to recall you mentioning that that
> > > doesn't work sanely anymore? If so, perhaps we can just remove the !gcc
> > > variant?
> >
> > It still compiles, modulo some old and uninteresting warnings, but linking
> > the postgres executable fails with
> >
> > usr/ccs/bin/ld: Unsatisfied symbols:
> > pg_compiler_barrier_impl (code)
> > make[2]: *** [postgres] Error 1
>
> 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. That
introduced:
+#elif defined(__hppa) || defined(__hppa__) /* HP PA-RISC */
+
+/* HPPA doesn't do either read or write reordering */
+#define pg_memory_barrier() pg_compiler_barrier()

That works well enough for hppa on gcc because there's generic compiler
barrier for the latter. But for HPUX on own compiler no compiler barrier
is defined, because:

/*
* If read or write barriers are undefined, we upgrade them to full memory
* barriers.
*
* If a compiler barrier is unavailable, you probably don't want a full
* memory barrier instead, so if you have a use case for a compiler barrier,
* you'd better use #ifdef.
*/
#if !defined(pg_read_barrier)
#define pg_read_barrier() pg_memory_barrier()
#endif
#if !defined(pg_write_barrier)
#define pg_write_barrier() pg_memory_barrier()
#endif

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

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services