On Thu, Aug 25, 2022 at 1:41 PM Tom Lane <tgl@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.
--
Robert Haas
EDB: http://www.enterprisedb.com
