pg_memory_barrier() doesn't compile, let alone work, for me

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: pg_memory_barrier() doesn't compile, let alone work, for me
Date: 2013-07-15 00:41:34
Message-ID: 11578.1373848894@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Commit 9a20a9b2 breaks the build for me, using gcc on HPPA:

xlog.c:2182: macro `pg_memory_barrier' used without args
xlog.c:2546: macro `pg_memory_barrier' used without args
make[4]: *** [xlog.o] Error 1

The reason for this is that the "fallback" definition of
pg_memory_barrier has been wrong since day one; it needs this fix:

-#define pg_memory_barrier(x) \
+#define pg_memory_barrier() \

However, fixing that doesn't yield much joy; initdb stalls and then
crashes with

PANIC: stuck spinlock (40054a88) detected at xlog.c:2182

The reason for that is that the code does not bother to initialize
"dummy_spinlock" anywhere. It might accidentally fail to fail
on machines where the unlocked state of a spinlock is all-zeroes
(given a compiler that's not picky about the incorrect macro usage)
... but HPPA is not such a machine.

Rather than trying to think of a fix for that, I'm of the opinion that
we should rip this out. The fallback implementation of pg_memory_barrier
ought to be pg_compiler_barrier(), on the theory that non-mainstream
architectures don't have weak memory ordering anyway, or if they do you
need to do some work to get PG to work on them. Or maybe we ought to
stop pretending that the code is likely to work on arbitrary machines,
and just #error if there's not a supplied machine-specific macro.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-07-15 01:08:11 Re: Improvement of checkpoint IO scheduler for stable transaction responses
Previous Message Greg Smith 2013-07-15 00:09:50 Re: Changing recovery.conf parameters into GUCs