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. -- Robert Haas EDB: http://www.enterprisedb.com
