Re: V14 and later build the backend with -lpthread
От | Thomas Munro |
---|---|
Тема | Re: V14 and later build the backend with -lpthread |
Дата | |
Msg-id | CA+hUKGJeQOexM4pX8+RTziBamV_sLDbk1zFXO4emr3Q5PK+uAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: V14 and later build the backend with -lpthread (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: V14 and later build the backend with -lpthread
|
Список | 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?
Вложения
В списке pgsql-hackers по дате отправления: