V14 and later build the backend with -lpthread

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: V14 and later build the backend with -lpthread
Date: 2022-08-25 17:41:49
Message-ID: 1534517.1661449309@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/25662.1560896200%40sss.pgh.pa.us

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2022-08-25 17:49:20 Re: postgres_fdw hint messages
Previous Message Pavel Stehule 2022-08-25 17:40:57 Re: Schema variables - new implementation for Postgres 15