Re: Tom Lane 2016-10-08 <29244.1475959928@sss.pgh.pa.us>
> So I'm still of the opinion that there's not likely to be any meaningful
> performance difference in practice, at least not on reasonably recent
> Linux machines. But this does indicate that if there is any difference,
> it will probably favor switching.
Another data point that's admittedly much more of a footnote than
serious input to the original question is the following: Debian has a
(so far mostly toy) port "hurd-i386" which is using the GNU hurd
kernel along with the usual GNU userland that's also in use on Linux.
This OS doesn't implement any semaphores yet (PG compiles, but initdb
dies with ENOSYS immediately). On talking to the porters, they advised
that POSIX semaphores would have the best chances to get implemented
first, so I added USE_UNNAMED_POSIX_SEMAPHORES=1 to the architecture
template to be prepared for that.
Christoph
(The patch quoted below is obviously Debian-specific and not meant for
inclusion upstream.)
hurd doesn't support sysv semaphores (semget), and needs -pthread to find
sem_init. POSIX semaphores shared between processes (sem_init(pshared = 1))
aren't supported yet either, but have the best chance to get implemented, so be
prepared.
FATAL: could not create semaphores: Function not implemented
DETAIL: Failed system call was semget(1, 17, 03600).
undefined reference to symbol 'sem_init@@GLIBC_2.12'
--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -109,6 +109,10 @@ endifendif # aix
+ifeq ($(shell dpkg-architecture -qDEB_HOST_ARCH_OS), hurd)
+LIBS += -pthread
+endif # hurd
+# Update the commonly used headers before building the subdirectories$(SUBDIRS:%=%-recursive): | generated-headers
--- a/src/template/linux
+++ b/src/template/linux
@@ -28,3 +28,10 @@ if test "$SUN_STUDIO_CC" = "yes" ; then ;; esacfi
+
+# force use of POSIX instead of SysV semaphores on hurd-i386
+case $(dpkg-architecture -qDEB_HOST_ARCH) in
+ hurd*)
+ USE_UNNAMED_POSIX_SEMAPHORES=1
+ ;;
+esac
