Re: Remove pthread_is_threaded_np() checks in postmaster
От | Tristan Partin |
---|---|
Тема | Re: Remove pthread_is_threaded_np() checks in postmaster |
Дата | |
Msg-id | CYMF1TSN6CWG.17UM5FMXUDURU@neon.tech обсуждение исходный текст |
Ответ на | Re: Remove pthread_is_threaded_np() checks in postmaster ("Tristan Partin" <tristan@neon.tech>) |
Ответы |
Re: Remove pthread_is_threaded_np() checks in postmaster
|
Список | pgsql-hackers |
On Tue Jan 23, 2024 at 2:10 PM CST, Tristan Partin wrote: > On Tue Jan 23, 2024 at 1:47 PM CST, Andres Freund wrote: > > Hi, > > On 2024-01-23 13:20:15 -0600, Tristan Partin wrote: > > > These checks are not effective for what they are trying to prevent. A recent > > > commit[0] in libcurl when used on macOS has been tripping the > > > pthread_is_threaded_np() check in postmaster.c for shared_preload_libraries > > > entries which use libcurl (like Neon). Under the hood, libcurl calls > > > SCDynamicStoreCopyProxies[1], which apparently causes the check to fail. > > > > Maybe I'm missing something, but isn't that indicating the exact opposite, > > namely that the check is precisely doing what it's intended? > > The logic in the original commit seems sound: > > > On Darwin, detect and report a multithreaded postmaster. > > > > Darwin --enable-nls builds use a substitute setlocale() that may start a > > thread. Buildfarm member orangutan experienced BackendList corruption > > on account of different postmaster threads executing signal handlers > > simultaneously. Furthermore, a multithreaded postmaster risks undefined > > behavior from sigprocmask() and fork(). Emit LOG messages about the > > problem and its workaround. Back-patch to 9.0 (all supported versions). > > Some reading from signal(7): > > > A process-directed signal may be delivered to any one of the threads > > that does not currently have the signal blocked. If more than one of > > the threads has the signal unblocked, then the kernel chooses an > > arbitrary thread to which to deliver the signal. > > So it sounds like the commit is trying to protect from the last > sentence. > > And then forks only copy from their parent thread... What is keeping us from using pthread_sigmask(3) instead of sigprocmask(2)? If an extension can guarantee that threads that get launched by it don't interact with anything Postgres-related, would that be enough to protect from any fork(2) related issues? In the OP example, is there any harm in the thread that libcurl inadvertantly launches from a Postgres perspective? -- Tristan Partin Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: