Re: Remove pthread_is_threaded_np() checks in postmaster - Mailing list pgsql-hackers

From Tristan Partin
Subject Re: Remove pthread_is_threaded_np() checks in postmaster
Date
Msg-id CYMF1TSN6CWG.17UM5FMXUDURU@neon.tech
Whole thread Raw
In response to Re: Remove pthread_is_threaded_np() checks in postmaster  ("Tristan Partin" <tristan@neon.tech>)
Responses Re: Remove pthread_is_threaded_np() checks in postmaster
List 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 by date:

Previous
From: Dave Cramer
Date:
Subject: Re: [PATCH] Add native windows on arm64 support
Next
From: Vladimir Churyukin
Date:
Subject: Re: Multiple startup messages over the same connection