Re: Remove pthread_is_threaded_np() checks in postmaster

From: "Tristan Partin" <tristan(at)neon(dot)tech>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Alexander Bayandin" <alexander(at)neon(dot)tech>
Subject: Re: Remove pthread_is_threaded_np() checks in postmaster
Date: 2024-01-23 20:10:48
Message-ID: CYMCXQ79IJLC.2YKDPO24G2U3Q@neon.tech
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Please ignore this thread. I need to think of a better solution to this
problem.

--
Tristan Partin
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-01-23 20:15:12 Re: the s_lock_stuck on perform_spin_delay
Previous Message Andres Freund 2024-01-23 20:07:04 Re: the s_lock_stuck on perform_spin_delay