Make fallback implementation of pg_memory_barrier() work.
authorTom Lane <[email protected]>
Sat, 17 May 2014 22:29:46 +0000 (18:29 -0400)
committerTom Lane <[email protected]>
Sat, 17 May 2014 22:29:46 +0000 (18:29 -0400)
The fallback implementation involves acquiring and releasing a spinlock
variable that is otherwise unreferenced --- not even to the extent of
initializing it.  This accidentally fails to fail on platforms where
spinlocks should be initialized to zeroes, but elsewhere it results in
a "stuck spinlock" failure during startup.

I griped about this last July, and put in a hack that worked for gcc
on HPPA, but didn't get around to fixing the general case.  Per the
discussion back then, the best thing to do seems to be to initialize
dummy_spinlock in main.c.

src/backend/main/main.c

index 4a563741e91c7eccb10ff2d87a4d23476c82c1a6..c6fb8c9fbe5ace8419fa3401e2957d58b2b3b7c7 100644 (file)
@@ -37,6 +37,8 @@
 #include "bootstrap/bootstrap.h"
 #include "common/username.h"
 #include "postmaster/postmaster.h"
+#include "storage/barrier.h"
+#include "storage/spin.h"
 #include "tcop/tcopprot.h"
 #include "utils/help_config.h"
 #include "utils/memutils.h"
@@ -288,6 +290,12 @@ startup_hacks(const char *progname)
        SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
    }
 #endif   /* WIN32 */
+
+   /*
+    * Initialize dummy_spinlock, in case we are on a platform where we have
+    * to use the fallback implementation of pg_memory_barrier().
+    */
+   SpinLockInit(&dummy_spinlock);
 }