Re: Remove pthread_is_threaded_np() checks in postmaster

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)