Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 44cd47c

Browse files
committed
Make fallback implementation of pg_memory_barrier() work.
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.
1 parent c1907f0 commit 44cd47c

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

src/backend/main/main.c

+8
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,8 @@
3737
#include "bootstrap/bootstrap.h"
3838
#include "common/username.h"
3939
#include "postmaster/postmaster.h"
40+
#include "storage/barrier.h"
41+
#include "storage/spin.h"
4042
#include "tcop/tcopprot.h"
4143
#include "utils/help_config.h"
4244
#include "utils/memutils.h"
@@ -288,6 +290,12 @@ startup_hacks(const char *progname)
288290
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
289291
}
290292
#endif /* WIN32 */
293+
294+
/*
295+
* Initialize dummy_spinlock, in case we are on a platform where we have
296+
* to use the fallback implementation of pg_memory_barrier().
297+
*/
298+
SpinLockInit(&dummy_spinlock);
291299
}
292300

293301

0 commit comments

Comments
 (0)