Require memory barrier support.

Previously we had a fallback implementation that made a harmless system
call, based on the assumption that system calls must contain a memory
barrier.  That shouldn't be reached on any current system, and it seems
highly likely that we can easily find out how to request explicit memory
barriers, if we've already had to find out how to do atomics on a
hypothetical new system.

Removed comments and a function name referred to a spinlock used for
fallback memory barriers, but that changed in 1b468a13, which left some
misleading words behind in a few places.

Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Suggested-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/721bf39a-ed8a-44b0-8b8e-be3bd81db748%40technowledgy.de
Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us

src/backend/port/atomics.c

@@ -17,29 +17,6 @@
 #include "port/atomics.h"
 #include "storage/spin.h"
 
-#ifdef PG_HAVE_MEMORY_BARRIER_EMULATION
-#ifdef WIN32
-#error "barriers are required (and provided) on WIN32 platforms"
-#endif
-#include <signal.h>
-#endif
-
-#ifdef PG_HAVE_MEMORY_BARRIER_EMULATION
-void
-pg_spinlock_barrier(void)
-{
-	/*
-	 * NB: we have to be reentrant here, some barriers are placed in signal
-	 * handlers.
-	 *
-	 * We use kill(0) for the fallback barrier as we assume that kernels on
-	 * systems old enough to require fallback barrier support will include an
-	 * appropriate barrier while checking the existence of the postmaster pid.
-	 */
-	(void) kill(PostmasterPid, 0);
-}
-#endif
-
 
 #ifdef PG_HAVE_ATOMIC_U64_SIMULATION