Re: V14 and later build the backend with -lpthread

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: V14 and later build the backend with -lpthread
Date: 2022-08-25 20:51:44
Message-ID: CA+hUKGJeQOexM4pX8+RTziBamV_sLDbk1zFXO4emr3Q5PK+uAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 26, 2022 at 8:40 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Aug 25, 2022 at 1:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
0001-Avoid-adding-pthread-to-backend-unintentionally.patch text/x-patch 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-25 20:56:12 Re: V14 and later build the backend with -lpthread
Previous Message Tom Lane 2022-08-25 20:41:07 Re: has_privs_of_role vs. is_member_of_role, redux