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
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 |