On Fri, Aug 26, 2022 at 8:40 AM Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Aug 25, 2022 at 1:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> > I realized $SUBJECT while wondering why my new buildfarm animal chickadee
> > (NetBSD on gaur's old hardware) fails the plpython tests on v13 and
> > earlier. After a bit of investigation I realized it *should* be failing,
> > because neither NetBSD nor Python have done anything about the problem
> > documented in [1]. The reason it fails to fail in current branches is
> > that we're now pulling -lpthread into the backend, which AFAICT is an
> > unintentional side-effect of sloppy autoconfmanship in commits
> > de91c3b97 / 44bf3d508. We wanted pthread_barrier_wait() for pgbench,
> > not the backend, but as-committed we'll add -lpthread to LIBS if it
> > provides pthread_barrier_wait.
> >
> > Now maybe someday we'll be brave enough to make the backend multithreaded,
> > but today is not that day, and in the meantime this seems like a rather
> > dangerous situation. There has certainly been exactly zero analysis
> > of whether it's safe.
> >
> > ... On the third hand, poking at backends with ldd shows that at
> > least on Linux, we've been linking the backend with -lpthread for
> > quite some time, back to 9.4 or so. The new-in-v14 behavior is that
> > it's getting in there on BSD-ish platforms as well.
> >
> > Should we try to pull that back out, or just cross our fingers and
> > hope there's no real problem?
>
> Absent some evidence of a real problem, I vote for crossing our
> fingers. It would certainly be a very bad idea to start using pthreads
> willy-nilly in the back end, but the mere presence of the library
> doesn't seem like a particularly severe issue. I might feel
> differently if no such version had been released yet, but it's hard to
> feel like the sky is falling if it's been like this on Linux since
> 9.4.
I suspect we will end up linked against the threading library anyway
in real-world builds via --with-XXX (I see that --with-icu has that
effect on my FreeBSD system, but I know that details about threading
are quite different in NetBSD). I may lack imagination but I'm
struggling to see how it could break anything.
How should I have done that, by the way? Is the attached the right trick?
From 761158cb38508dbb91ca7fff474b4f6e041583a7 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.mu...@gmail.com>
Date: Fri, 26 Aug 2022 08:16:12 +1200
Subject: [PATCH] Avoid adding -pthread to backend unintentionally.
---
configure | 35 +++++++++++++++++------------------
configure.ac | 7 +++----
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/configure b/configure
index 814014a96b..fefe97e520 100755
--- a/configure
+++ b/configure
@@ -647,13 +647,13 @@ MSGFMT
PG_CRC32C_OBJS
CFLAGS_ARMV8_CRC32C
CFLAGS_SSE42
-LIBOBJS
ZSTD
LZ4
UUID_LIBS
LDAP_LIBS_BE
LDAP_LIBS_FE
with_ssl
+LIBOBJS
PTHREAD_CFLAGS
PTHREAD_LIBS
PTHREAD_CC
@@ -12429,6 +12429,7 @@ fi
if test "$enable_thread_safety" = yes; then
+ _LIBS="$LIBS"
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing pthread_barrier_wait" >&5
$as_echo_n "checking for library containing pthread_barrier_wait... " >&6; }
if ${ac_cv_search_pthread_barrier_wait+:} false; then :
@@ -12485,6 +12486,21 @@ if test "$ac_res" != no; then :
fi
+ ac_fn_c_check_func "$LINENO" "pthread_barrier_wait" "ac_cv_func_pthread_barrier_wait"
+if test "x$ac_cv_func_pthread_barrier_wait" = xyes; then :
+ $as_echo "#define HAVE_PTHREAD_BARRIER_WAIT 1" >>confdefs.h
+
+else
+ case " $LIBOBJS " in
+ *" pthread_barrier_wait.$ac_objext "* ) ;;
+ *) LIBOBJS="$LIBOBJS pthread_barrier_wait.$ac_objext"
+ ;;
+esac
+
+fi
+
+
+ LIBS="$_LIBS"
fi
if test "$with_readline" = yes; then
@@ -16369,23 +16385,6 @@ fi
-if test "$enable_thread_safety" = yes; then
- ac_fn_c_check_func "$LINENO" "pthread_barrier_wait" "ac_cv_func_pthread_barrier_wait"
-if test "x$ac_cv_func_pthread_barrier_wait" = xyes; then :
- $as_echo "#define HAVE_PTHREAD_BARRIER_WAIT 1" >>confdefs.h
-
-else
- case " $LIBOBJS " in
- *" pthread_barrier_wait.$ac_objext "* ) ;;
- *) LIBOBJS="$LIBOBJS pthread_barrier_wait.$ac_objext"
- ;;
-esac
-
-fi
-
-
-fi
-
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
# Cygwin and (apparently, based on test results) Mingw both
# have a broken strtof(), so substitute its implementation.
diff --git a/configure.ac b/configure.ac
index 6ff294d405..c51f174fde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1260,7 +1260,10 @@ AC_SEARCH_LIBS(shmget, cygipc)
AC_SEARCH_LIBS(backtrace_symbols, execinfo)
if test "$enable_thread_safety" = yes; then
+ _LIBS="$LIBS"
AC_SEARCH_LIBS(pthread_barrier_wait, pthread)
+ AC_REPLACE_FUNCS([pthread_barrier_wait])
+ LIBS="$_LIBS"
fi
if test "$with_readline" = yes; then
@@ -1831,10 +1834,6 @@ AC_REPLACE_FUNCS(m4_normalize([
strnlen
]))
-if test "$enable_thread_safety" = yes; then
- AC_REPLACE_FUNCS(pthread_barrier_wait)
-fi
-
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
# Cygwin and (apparently, based on test results) Mingw both
# have a broken strtof(), so substitute its implementation.
--
2.37.1
