Re: V14 and later build the backend with -lpthread - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: V14 and later build the backend with -lpthread
Date
Msg-id CA+hUKGJeQOexM4pX8+RTziBamV_sLDbk1zFXO4emr3Q5PK+uAg@mail.gmail.com
Whole thread Raw
In response to Re: V14 and later build the backend with -lpthread  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: V14 and later build the backend with -lpthread
List pgsql-hackers
On Fri, Aug 26, 2022 at 8:40 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

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?

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: has_privs_of_role vs. is_member_of_role, redux
Next
From: Tom Lane
Date:
Subject: Re: V14 and later build the backend with -lpthread