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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
